Global data source asset map automatic generation method

Abstract

This application provides a method for automatically generating a full-domain data source asset map, comprising: acquiring multi-source heterogeneous data in a financial user risk assessment scenario and extracting its metadata to generate original risk assessment metadata, wherein the multi-source heterogeneous data is matched to a user basic information domain, a behavioral feature domain, and an external association domain; performing bidirectional semantic mapping annotation on the original risk assessment metadata based on a user credit status assessment dimension and a user performance capability assessment dimension to generate risk assessment labeled metadata with data domain affiliation tags; constructing a traceable data lineage link based on the risk assessment labeled metadata to generate a risk assessment metadata lineage graph containing inter-domain relationships; and constructing full-domain cross-domain data association rules based on the risk assessment metadata lineage graph to generate a full-domain data source asset map. This application achieves unified management of data assets across the entire domain, effectively solving the technical limitations of traditional solutions.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a method for automatically generating asset maps from a global data source. Background Technology

[0002] When conducting user risk assessment in the financial sector, it is necessary to integrate multi-source heterogeneous data that are scattered across user basic information domains, behavioral characteristic domains, and external related domains. These data have different format specifications, semantic definitions, and flow paths. The accuracy and efficiency of risk assessment depend heavily on the clear management of these data assets. It is necessary to present the distribution range, correlation logic, and flow trajectory of the data in an effective way to support source tracing and compliance verification during the data retrieval process, and meet the core requirements of risk assessment for manageable, traceable, and usable data assets.

[0003] Current data asset management solutions for this scenario typically adopt an approach of "independent processing within a domain - fixed integration between domains". First, for the user basic information domain, behavioral feature domain, and external association domain, each domain-specific metadata extraction standard is used to obtain the field attributes and storage information of the data within the domain. Then, based on pre-defined field name matching rules (such as uniform association of the "user ID" field), preliminary associations between different data domains are established. Finally, the metadata information of each domain is integrated with the preliminary association results between domains to form a data asset display view for risk assessment.

[0004] Such solutions have significant technical limitations: because inter-domain associations rely solely on fixed matching of field names, they do not consider the semantic differences of data with the same business meaning in different data domains (such as the same user identifier being labeled as "user number" in the basic information domain and "account ID" in the behavioral feature domain). This results in fragmented association logic for data assets across domains, making it impossible to form a unified data asset association system covering the user's basic information domain, behavioral feature domain, and external association domain. The final asset view cannot fully reflect the entire data flow trajectory, and data associations need to be verified across multiple domains during the risk assessment data tracing process. This not only increases the complexity of data asset retrieval but also reduces the overall processing efficiency of risk assessment business. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a method for automatically generating asset maps from a global data source, thereby at least alleviating the aforementioned technical issues.

[0006] The technical solutions provided in this application are as follows:

[0007] This application provides a method for automatically generating asset maps from a global data source, which includes:

[0008] Step 1: Acquire multi-source heterogeneous data in the financial user risk assessment scenario and extract its metadata to generate original risk assessment metadata. The multi-source heterogeneous data is matched to the user basic information domain, behavioral feature domain, and external association domain. Step 2: Perform bidirectional semantic mapping annotation on the original risk assessment metadata based on the user credit status assessment dimension and the user performance capability assessment dimension to generate risk assessment labeled metadata with data domain affiliation labels. Step 3: Construct a traceable data lineage link based on the risk assessment labeled metadata to generate a risk assessment metadata lineage map containing inter-domain relationships. Step 4: Construct cross-domain data association rules based on the risk assessment metadata lineage map to generate a full-domain data source asset map.

[0009] The technical solution in this application has the following technical advantages:

[0010] 1. To address the problem of traditional solutions where "metadata is extracted independently from each data domain using proprietary standards, resulting in fragmentation between initial data asset domains," this method, through step 1, "acquires multi-source heterogeneous data matching the user basic information domain, behavioral characteristic domain, and external association domain in a financial user risk assessment scenario, and extracts metadata from it to generate original risk assessment metadata." This method uses a unified metadata extraction logic to process heterogeneous data from the three data domains, rather than the traditional independent extraction model between domains. This lays the foundation for the unified association and management of cross-domain data assets in the future, reducing the fragmentation between data assets from the initial stage.

[0011] 2. To address the problem that traditional solutions rely on fixed field name matching to establish inter-domain associations, which cannot cope with the fragmentation of association logic caused by semantic differences between different data domains, this method, through step 2, "generates risk assessment labeled metadata with data domain affiliation tags by performing bidirectional semantic mapping annotation on the original risk assessment metadata based on the user credit status assessment dimension and the user performance capability assessment dimension." Using the two core business dimensions of the risk assessment scenario as the semantic association benchmark, rather than the traditional surface matching of field names, it can identify data in different data domains that have different expressions but consistent business meanings (such as the user basic information domain "user number" and the behavioral feature domain "account ID"), significantly improving the consistency of data asset association logic between domains and avoiding fragmentation of association logic.

[0012] 3. To address the problem of traditional solutions failing to trace data flow paths, resulting in the asset view not reflecting the entire data flow path, this method, through step 3, "constructs a traceable data lineage based on risk assessment annotation metadata to generate a risk assessment metadata lineage map containing inter-domain relationships," proactively traces the entire data flow information from collection to application (including intra-domain and inter-domain flows), rather than the traditional approach of merely integrating static metadata. This makes the entire data asset flow trajectory clearly traceable, providing direct and complete path evidence for data tracing in risk assessment.

[0013] 4. Addressing the issue that traditional solutions "fixedly integrate asset information from various domains, failing to form a unified data asset association system across the entire domain, leading to the need for cross-domain verification for tracing," this method, through step 4 "constructing cross-domain data association rules based on the risk assessment metadata lineage map to generate a full-domain data source asset map," dynamically constructs cross-domain association rules based on a complete lineage chain, rather than the traditional fixed field mapping integration, forming a unified data asset association system covering user basic information domain, behavioral characteristic domain, and external association domain. When calling data during the risk assessment process, the data association relationship and flow trajectory can be directly queried through the full-domain data source asset map, eliminating the need for cross-domain verification, reducing the complexity of data asset retrieval, and thus improving the overall processing efficiency of risk assessment business. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating a method for automatically generating a global data source asset map according to an embodiment of this application.

[0015] Figure 2 This is a schematic diagram of the structure of an automatic generation device for a global data source asset map according to an embodiment of this application. Detailed Implementation

[0016] Figure 1 This is a flowchart illustrating a method for automatically generating a global data source asset map according to an embodiment of this application. Figure 1 As shown, it includes:

[0017] Step 1: Obtain multi-source heterogeneous data in the financial user risk assessment scenario and extract its metadata to generate original metadata for risk assessment. The multi-source heterogeneous data is matched with the user basic information domain, behavioral feature domain, and external association domain.

[0018] Step 2: Perform bidirectional semantic mapping annotation on the original risk assessment metadata based on the user credit status assessment dimension and the user performance capability assessment dimension to generate risk assessment labeled metadata with data domain attribution tags;

[0019] Step 3: Construct a traceable data lineage based on risk assessment annotation metadata to generate a risk assessment metadata lineage map containing inter-domain relationships;

[0020] Step 4: Based on the risk assessment metadata lineage map, construct cross-domain data association rules to generate a full-domain data source asset map.

[0021] Optionally, step 1 specifically involves: obtaining multi-source heterogeneous data from independent storage nodes of the user basic information domain, behavioral feature domain, and external association domain to generate basic metadata fields; and generating risk assessment raw metadata containing full-domain data domain coverage information in the user basic information domain, behavioral feature domain, and external association domain based on the basic metadata fields.

[0022] Optionally, step 1 specifically includes: Step 11: Based on a preset distributed cross-domain data acquisition protocol, multi-source heterogeneous data is obtained from independent storage nodes of the user basic information domain, behavioral feature domain, and external association domain, respectively. The multi-source heterogeneous data includes structured data, semi-structured data, and unstructured data.

[0023] Optionally, step 11 specifically includes the following steps:

[0024] Step 111: Construct a data domain identity authentication center and assign cross-domain access tokens to each independent storage node of the user basic information domain, behavioral feature domain, and external association domain;

[0025] Step 112: Establish an encrypted data transmission channel based on the cross-domain access token. The encrypted data transmission channel uses an inter-domain key negotiation mechanism to dynamically generate session keys.

[0026] Step 113: Send a timestamped collection instruction to the user basic information domain, behavioral feature domain, and external association domain through an encrypted data transmission channel. The collection instruction includes data domain-specific filtering rules for filtering by identity in the user basic information domain, by time window in the behavioral feature domain, and by association strength in the external association domain.

[0027] Step 114: Receive encrypted data packets returned from the user basic information domain, behavioral feature domain, and external association domain, and verify the data packet signature of the encrypted data packet through the data domain identity authentication center to obtain multi-source heterogeneous data after decryption.

[0028] Preferably, the specific implementation process of step 111 is as follows: First, for the user basic information domain, behavioral characteristic domain, and external association domain in the financial user risk assessment scenario, a data domain identity authentication center is constructed. This data domain identity authentication center includes two core units: a node identity registry generation module and a cross-domain access token generation module. The node identity registry generation module first collects the basic information of each independent storage node in the three data domains (including the data domain name to which the storage node belongs, the node's physical address, the node's management permission level, and the data transmission protocol type supported by the node). This basic information is then organized according to the field structure of "data domain name - node physical address - permission level - transmission protocol" to generate a node identity registry specific to each data domain. This node identity registry is used to uniquely identify the identity and functional attributes of each independent storage node. Next, the cross-domain access token generation module calls the information in the node identity registry to generate a unique cross-domain access token for each independent storage node. The structure of the cross-domain access token includes "data domain identifier segment (the name of the data domain to which the node belongs) - node code segment (the hash value of the physical address of the corresponding node) - permission identifier segment (the management permission level of the corresponding node) - validity period segment (the preset validity period of the token)". The generated cross-domain access token is bound to the corresponding node information in the node identity registry to form a token-node association table. This token-node association table is used to verify the legality of the cross-domain access token in the future, and finally completes the construction of the data domain identity authentication center and the distribution of cross-domain access tokens.

[0029] Preferably, in the specific technical implementation of step 112: First, using the cross-domain access token generated in step 111 as identity credential, a request to establish an encrypted data transmission channel is initiated. This request carries the permission identifier segment information of the cross-domain access token. Next, the target data domain storage node receiving the request calls the token verification module of the data domain identity authentication center to compare the cross-domain access token in the request with the token-node association table to verify the validity of the token (including whether the token is within the valid duration period and whether the permission identifier segment matches the node management permission level). After successful verification, the inter-domain key negotiation mechanism is initiated. This inter-domain key negotiation mechanism differs from the traditional Diffie-Hellman algorithm. Addressing the real-time data transmission requirements in financial user risk assessment scenarios, it reduces two key exchange steps. Specifically: First, the initiating end generates a temporary public key and sends it along with a node code segment containing a cross-domain access token to the receiving end. The receiving end retrieves the initiating end's node physical address from the token-node association table based on the node code segment, and generates a session key base value by combining it with its own temporary private key. Then, the receiving end sends its temporary public key and the session key base value back to the initiating end. The initiating end combines its own temporary private key and the session key base value to generate the final session key, which is used to encrypt all subsequent data transmissions. Finally, based on the generated session key, the encryption algorithm (using AES-256, with the session key as the encryption key) and integrity verification algorithm (using SHA-256) are configured for data transmission, forming an encrypted data transmission channel. This encrypted data transmission channel ensures the security and real-time performance of cross-domain data transmission, meeting the compliance requirements for data transmission in financial scenarios.

[0030] Preferably, in a scenario, step 113 is specifically implemented as follows: First, based on the business requirements of the financial user risk assessment scenario, a data collection instruction with a timestamp is generated. The structure of the data collection instruction includes "instruction header (identifying the instruction type as data collection) - timestamp segment (the current time accurate to milliseconds, used to prevent instruction replay attacks) - data domain filtering rule segment (exclusive filtering rules corresponding to the three data domains) - instruction tail (instruction verification code)". The data domain filtering rules section designs specific rules for different data domains: For the user basic information domain, the filtering rule is "filter by identity identifier," meaning only heterogeneous data containing a user's unique identity identifier (such as the hash value of the user's ID number or the unique code of the user's account) is collected. This identity identifier must match the identity information of the risk assessment object to avoid collecting basic information of irrelevant users. For the behavioral feature domain, the filtering rule is "filter by time window," meaning only heterogeneous user behavior data (such as user login behavior, operation behavior) within a preset time window (this time window is determined according to the timeliness requirements of the risk assessment model for behavioral data, such as the past 3 months or the past 6 months; in general implementation, it can be configured as an adjustable time parameter, and in specific scenarios, it can be set to the past 3 months) is collected. Records are kept to ensure that the collected behavioral data has high reference value. For external related domains, the filtering rule is "filter by association strength". That is, the association strength value between external data (such as third-party credit assessment data, public information data) and risk assessment objects is calculated first (this association strength value is calculated by "data field matching degree (such as the matching degree of name and identity identifier) ​​× data update timeliness (such as the weight of the interval between data generation time and collection time)"). In general implementation, the weights of matching degree and timeliness are configurable. In specific scenarios, the matching degree weight is set to 0.6 and the timeliness weight is set to 0.4. Only external heterogeneous data with association strength values ​​exceeding the preset threshold (the threshold is configurable in general implementation, and is set to 0.7 in specific scenarios) are collected to reduce the amount of invalid external data collected. Next, the generated timestamp-embedded collection command is transmitted to the encrypted data transmission channel established in step 112. Through this channel, the command is sent to the corresponding storage nodes of the user basic information domain, behavior feature domain, and external association domain. After receiving the collection command, each storage node first verifies the validity of the checksum and timestamp segment at the end of the command. After successful verification, it parses the content of the data domain filtering rule segment and prepares to execute the data collection operation.

[0031] Preferably, the specific implementation process of step 114 is as follows: First, receive the encrypted data packets returned by the storage nodes of the user basic information domain, behavioral feature domain, and external association domain through the encrypted data transmission channel. The structure of the encrypted data packet includes "data packet signature segment (digital signature of the storage node) - ciphertext segment (encrypted content of the collected heterogeneous data) - data description segment (number of fields and data format type of the collected data)". Next, call the signature verification module of the data domain identity authentication center to obtain the public key of the corresponding storage node from the token-node association table. Use the public key to verify the data packet signature segment of the encrypted data packet. If the verification is successful, the source of the data packet is confirmed to be legitimate. If the verification fails, the encrypted data packet is directly discarded (to prevent illegal data from entering the subsequent processing flow, which meets the data security requirements of financial scenarios). Then, pass the ciphertext segment of the verified encrypted data packet to the decryption module corresponding to the session key generated in step 112. Use the session key to decrypt the ciphertext segment to obtain the original collected data. Subsequently, based on the data description segment information of the encrypted data packet, the format of the decrypted raw collected data is validated—that is, it is checked whether the user basic information field data contains an identity field, whether the behavioral feature field data is within a preset time window, and whether the association strength value of the external association field data meets the filtering rules. Collected data that passes the validation is classified as valid collected data, and collected data that fails the validation is marked as invalid data and the reason for invalidity is recorded (such as the behavioral feature field data exceeding the time window). Finally, the valid collected data from the three data fields are integrated to form multi-source heterogeneous data in the financial user risk assessment scenario. This multi-source heterogeneous data is used as the "heterogeneous data obtained" in step 12 for subsequent field-level standardized parsing processing.

[0032] Optionally, step 1 specifically includes: Step 12: Perform field-level standardized parsing on the acquired heterogeneous data to extract field definitions, data types, format specifications and source system identifiers, and generate basic metadata fields;

[0033] Preferably, the specific implementation process of step 12 is as follows: First, the processing object is determined to be the multi-source heterogeneous data (including structured data of user basic information domain, semi-structured data of behavioral feature domain, and unstructured data of external association domain) obtained in the financial user risk assessment scenario in step 114. Based on the characteristics of the three different types of structured data, a differentiated field-level standardization parsing strategy is adopted to improve the adaptability of the parsing results to the risk assessment scenario.

[0034] For structured data in the user basic information domain (such as a user information table in a relational database), the table structure definition (including field names, field lengths, and constraints) is first read through the structured data parsing module. This parsing process reveals the field hierarchy (no nested levels; fields directly correspond to the table structure). Next, the field definition is extracted for each field—combining the needs of financial user risk assessment scenarios, the business meaning of the fields is clarified (e.g., the "User ID" field is defined as "a 10-digit code used to uniquely identify the risk assessment object, with the first two digits being the regional code and the last eight digits being the serial number," and the "Date of Birth" field is defined as "the date of birth of the risk assessment object, used to assist in determining age-related information related to repayment ability"). Then, the data is further extracted... According to the data type (e.g., "User ID" is a string, "Date of Birth" is a date, and "Amount of Realizable Assets" is a numeric type); then, the format is standardized according to the preset financial data format specifications (e.g., date fields are uniformly formatted as "YYYY-MM-DD", numeric fields are uniformly retained to 2 decimal places, and leading and trailing spaces are removed from string fields); finally, the source system identifier is extracted (e.g., the structured data comes from "User Basic Information Management System V3.1", and the identifier is obtained from the system attribution tag of the data), and this information is organized according to the structure of "Field Name-Field Definition-Data Type-Format Specification-Source System Identifier" to generate a structured data field parsing table. This structured data field parsing table serves as a reference benchmark for subsequent semi-structured data parsing.

[0035] For semi-structured data in the behavioral feature domain (such as user behavior logs in JSON format and operation records in XML format), the nested hierarchical structure of the data is first parsed using the semi-structured data parsing module (e.g., in JSON data, the "behavior record" node contains "login behavior" and "transaction behavior" sub-nodes, and the "login behavior" sub-node contains "login time" and "login IP" fields), resulting in a flattened field list. Next, referring to the field information structure of the structured data field parsing table, the field definition of each flattened field is extracted (e.g., the "login time" field is defined as "the time when the risk assessment object initiates the system login request, used to analyze the time distribution characteristics of user behavior," and the "login IP" field is defined as "the network IP address used by the risk assessment object when logging into the system, used to assist in judging the geographical consistency of behavior"). Then, the data type is extracted (e.g., "login time" is date / time type, and "login IP" is string type). Finally, it is processed uniformly according to format specifications (e.g., date / time type fields are uniformly formatted as "YYYY-MM-DD"). The format is "HH:MM:SS" (IP address field is uniformly in IPv4 standard format). Finally, the source system identifier is extracted (e.g., the semi-structured data comes from "User Behavior Analysis System V1.5"), and a semi-structured data field parsing table is generated. This table is then merged with the structured data field parsing table to obtain a preliminary integrated field parsing table.

[0036] For unstructured data from external related domains (such as credit assessment reports from third-party institutions and user performance documentation), the unstructured data parsing module first loads a dictionary specific to the financial user risk assessment domain (this dictionary contains core keywords for scenarios such as "overdue records," "number of performances," "credit rating," and "guarantee status," which differs from general dictionaries and improves the scenario adaptability of field extraction). A combination of keyword matching and semantic analysis is used to locate and extract valid fields from the text (e.g., extracting "overdue records" and "number of performances" from credit assessment reports). Next, the extracted fields are clearly defined (e.g., the "overdue records" field is defined as "the number of overdue payments for various credit transactions by the risk assessment object within the past 12 months, used to reflect..."). The "User Credit Status" and "Number of Fulfillments" fields are defined as "the number of credit transactions that the risk assessment object has fulfilled on time in the past 24 months, used to assist in judging its ability to fulfill obligations"; then, the data type is determined according to the business meaning of the fields (e.g., "Overdue Records" is numeric, "Credit Rating" is string); subsequently, they are processed uniformly according to format specifications (e.g., numeric fields are rounded to integers, and string fields are uniformly standardized with four levels: "Excellent / Good / Average / Poor"); finally, the source system identifier is extracted (e.g., the unstructured data comes from "a third-party credit service platform XX institution," and the identifier is obtained from the header information of the document), and an unstructured data field parsing table is generated. This table is then further merged with the initially integrated field parsing table to obtain the integrated field parsing table.

[0037] Next, the integrated field parsing table undergoes standardized validation: The format of each field is checked to ensure it conforms to preset financial data standards (e.g., whether numeric fields have more than two decimal places, and whether date fields conform to the "YYYY-MM-DD" format). If any discrepancies are found, they are corrected by referring to the format specifications of similar fields within the same data domain. Simultaneously, the completeness of the source system identifier is checked. If any are missing (e.g., some unstructured data lacks source labeling), the transmission source information of the corresponding data is extracted from the encrypted data packet description segment in step 114 to complete the source system identifier. After validation, a standardized field parsing table is generated. The four core pieces of information for each field—"field definition, data type, format specification, and source system identifier"—are extracted from this table and integrated according to the structure "field unique ID - field definition - data type - format specification - source system identifier" to finally generate a basic metadata field. This basic metadata field serves as the processing object for "adding data domain attribution identifiers to the basic metadata field" in step 13, ensuring a standardized foundation for subsequent metadata processing.

[0038] Optionally, step 1 specifically includes: Step 13: Adding a data domain affiliation identifier and a cross-domain association index code to the basic metadata field, wherein the cross-domain association index code is used to identify semantically related metadata fields in different data domains;

[0039] Preferably, the specific implementation process of step 13 is as follows: First, the processing object is determined to be the basic metadata field generated in step 12 (including field unique ID, field definition, data type, format specification, and source system identifier). In view of the characteristics of clear data domain division in the financial user risk assessment scenario, the processing is completed in two stages - first, add data domain ownership identifier, and then generate cross-domain association index code to achieve the clarification of data domain ownership and the initial establishment of cross-domain semantic association.

[0040] In the stage of adding data domain attribution identifiers: First, a data domain identifier mapping table is constructed. This table is based on the domain division rules of financial user risk assessment scenarios, binding the source system identifier with the data domain name (e.g., "User Basic Information Management System" is bound to "User Basic Information Domain", "User Behavior Analysis System" is bound to "Behavioral Feature Domain", and "Third-Party Credit Service Platform" is bound to "External Related Domain"). A unique domain identifier code is assigned to each data domain ("UBI" for the User Basic Information Domain, "BHD" for the Behavioral Feature Domain, and "ERD" for the External Related Domain). Next, each field in the basic metadata fields is traversed, the source system identifier of the field is extracted, and it is matched with the data domain identifier mapping table to determine the data domain to which the field belongs and the corresponding domain identifier code. Subsequently, a "Data Domain Attribution Identifier" field is added to each basic metadata field. The content of this field is a combination of "domain identifier code - data domain name" (e.g., "UBI - User Basic Information Domain", "BHD - Behavioral Feature Domain"), generating a list of metadata fields with domain identifiers. This list of metadata fields with domain identifiers not only clarifies the domain affiliation of each field, but also provides a basis for domain division for the subsequent generation of cross-domain association index codes. This differs from the traditional method of determining domain affiliation solely based on storage location, thus improving the accuracy of domain affiliation identification.

[0041] In the stage of generating cross-domain association index codes: Based on the list of metadata fields with domain identifiers, a semantic relevance calculation model is constructed. This model builds a dedicated semantic dictionary for core business terms in financial user risk assessment scenarios (such as "user identifier," "credit record," and "performance behavior") to improve the scenario adaptability of semantic matching between fields in different data domains. First, the field definition of each field in the list of metadata fields with domain identifiers is extracted. Then, a semantic word segmentation tool (combined with a scenario-specific semantic dictionary) is used to decompose the field definition into a sequence of keywords (e.g., the field definition of "user number" is decomposed into "unique identifier + risk assessment object + code," and the field definition of "account ID" is decomposed into "user + login + unique code"). Next, the keyword overlap and semantic distance between fields in different data domains are calculated (keyword overlap is the proportion of common keywords to the total number of keywords; semantic distance is calculated through the hierarchical relationship of keywords in the scenario-specific semantic dictionary, such as the core keywords "unique identifier" and "unique code" of "user ID" and "account ID" being synonymous in the dictionary, resulting in a low semantic distance). The two are weighted to obtain the field semantic relevance (in general implementations, the overlap weight is set to 0.6, and the semantic distance weight is set to 0.4; in specific scenarios, this can be adjusted according to the focus of the risk assessment model). Then, a semantic relevance threshold is set (the threshold is configurable in general implementations, and is set to 0.65 in specific scenarios), filtering out field groups in different data domains whose semantic relevance exceeds the threshold (e.g., "user ID" in the user basic information domain and "account ID" in the behavioral feature domain form one field group, and "ID number" in the user basic information domain and "document number" in the external association domain form another field group). Finally, a unique cross-domain association index code is assigned to each field group. This index code adopts the structure of "association group number - inter-domain association type" (e.g., "G001 - user identifier association", "G002 - document information association"). The "association group number" is a continuous numeric code, and the "inter-domain association type" is determined based on the business meaning of the field group (e.g., association types related to user identity are uniformly "user identifier association"). The cross-domain association index code is added to the metadata information of the corresponding field, generating a metadata field with a data domain affiliation identifier and the cross-domain association index code. This field serves as the processing object for "integrating basic metadata fields with data domain identifiers" in step 14, laying the semantic foundation for subsequent construction of full-domain data associations.

[0042] The entire process ensures the accuracy of data domain attribution and the rationality of cross-domain association through scenario-based domain identification rules and semantic relevance calculations. It solves the semantic misalignment problem caused by relying solely on field names for cross-domain association in traditional methods, and is particularly suitable for the characteristics of financial user risk assessment scenarios where the same business concept is expressed differently in different data domains.

[0043] Optionally, step 1 specifically includes: Step 14: Integrate the basic metadata fields with data domain identifiers to generate risk assessment raw metadata containing information covering all data domains in the user basic information domain, behavioral feature domain, and external association domain.

[0044] Preferably, the specific implementation process of step 14 is as follows: First, the processing object is determined to be the metadata field (including field unique ID, field definition, data type, format specification, source system identifier, data domain identifier, and cross-domain association index code) generated in step 13 with data domain ownership identifier and cross-domain association index code. In view of the requirements of financial user risk assessment scenario for the integrity of full-domain data coverage and the validity of association, a three-level processing logic of "layered integration - conflict verification - full-domain index" is adopted to realize the systematic integration of multi-domain metadata.

[0045] In the layered integration phase: First, metadata fields with domain identifiers are grouped according to their data domain affiliation, resulting in three independent data groups: the User Basic Information Domain Metadata Group, the Behavioral Feature Domain Metadata Group, and the External Association Domain Metadata Group. For each data group, an intra-domain field relationship graph is constructed—using the unique ID of the field as nodes and the business relationships between fields (such as "User ID" and "Name" both belonging to user identity information and having a direct association) as edges. This graph is used to visually represent the field relationship structure within a single data domain. Next, based on cross-domain association index codes, fields with the same index code in different data groups are cross-domain associated, and an inter-domain association bridging table is constructed (e.g., binding the "User ID" field in the User Basic Information Domain with the "Account ID" field in the Behavioral Feature Domain through the index code "G001-User Identifier Association"). This bridging table serves as the association hub connecting the three data groups. Subsequently, an initial integration was carried out using the approach of "intra-domain aggregation + cross-domain association": First, the intra-domain field relationship diagram of each data group was converted into an intra-domain metadata aggregation table (containing the field's unique ID, the data domain to which it belongs, core attributes, and a list of intra-domain associated fields). Then, the three intra-domain metadata aggregation tables were connected through an inter-domain association bridging table to form a preliminary global metadata integration table. This table was the first to realize the structured association of metadata from the three data domains.

[0046] During the conflict verification phase: For the initial full-domain metadata integration table, a field conflict detection mechanism specific to the financial scenario is initiated. This mechanism focuses on two types of conflicts: first, field definition conflicts (fields with the same cross-domain association index code in different data domains have substantial differences in their field definitions, such as "credit score" being defined as "third-party institution score" in the external association domain but misdefined as "internal behavior score" in the behavioral feature domain); second, format specification conflicts (fields with the same business meaning have incompatible format specifications in different data domains, such as the "date" field being "YYYY / MM / DD" in the user basic information domain but "DD-MM-YYYY" in the external association domain). Field definition conflicts are identified by comparing the text similarity of field definitions with the same cross-domain association index code (calculated using an edit distance algorithm; the similarity threshold is set to 0.8 in the general implementation, but can be adjusted in specific scenarios); format specification conflicts are identified by verifying the matching degree between the format specification and the preset financial data standard. For the detected conflicting fields, conflict handling suggestions are generated (the conflict suggestions are defined based on the field definitions of external related domains, as third-party data is more authoritative; for format conflicts, the suggestions are uniformly converted to the "YYYY-MM-DD" standard format). The initial global metadata integration table is revised according to the suggestions to obtain the conflict-verified global metadata integration table, which ensures the consistency of cross-domain field definitions and format compatibility.

[0047] In the full-domain index construction phase: Based on the full-domain metadata integration table after conflict verification, a full-domain metadata index system specifically for risk assessment scenarios is constructed. This system includes three levels of indexes: the first-level index is the data domain identifier (quickly locating the domain to which a field belongs), the second-level index is the cross-domain association index code (quickly querying semantically related cross-domain field groups), and the third-level index is the core keywords of the field (core terms such as "credit," "performance," and "identification" extracted from the field definition, supporting retrieval by business theme). The third-level indexes are bound to the full-domain metadata integration table after conflict verification to generate a full-domain metadata integration table containing index information. Finally, a full-domain coverage identifier is added to this table—the field coverage rate of each data domain is calculated (number of integrated fields / total number of fields in the domain). If the coverage rate of a data domain is lower than a preset threshold (generally set at 90%, which can be adjusted according to business importance in specific scenarios), it is noted in the identifier that there is a coverage gap in the domain and supplementary data collection is required; if all data domains reach the threshold, it is marked as "full-domain complete coverage." By integrating all the above information, the original metadata of risk assessment is finally generated. This metadata serves as the processing object for "bidirectional semantic mapping annotation of the original metadata of risk assessment" in step 2. The full-domain data domain coverage information and structured association relationships contained in this metadata provide a complete and consistent metadata foundation for subsequent semantic annotation.

[0048] This process differs from the traditional method of simply piecing together multi-domain metadata. It ensures clear association logic through layered integration, improves data consistency through scenario-based conflict verification, and enhances retrieval efficiency through a three-level indexing system. It is particularly suitable for the high requirements of financial users' risk assessment scenarios for data integrity and association validity.

[0049] Optionally, step 2 specifically involves: determining credit mapping pairs and performance mapping pairs based on the field semantic vectors of the original risk assessment metadata, as well as the vectors of user credit status assessment dimension sub-items and user performance capability assessment dimension sub-items; and generating risk assessment annotation metadata that simultaneously includes user credit status assessment dimension labels, user performance capability assessment dimension labels, and data domain affiliation labels based on the credit mapping pairs and performance mapping pairs.

[0050] Optionally, step 2 specifically includes: step 21: constructing a semantic mapping model with a bidirectional attention mechanism, wherein the input layer of the semantic mapping model receives the field semantic vector of the original metadata of risk assessment, as well as the sub-item vector of the user credit status assessment dimension and the sub-item vector of the user performance capability assessment dimension.

[0051] Preferably, the specific implementation process of step 21 is as follows: First, for the bidirectional semantic mapping requirements of financial user risk assessment scenarios, a semantic mapping model with a bidirectional attention mechanism is constructed. This model adopts a three-layer architecture of "input layer - bidirectional attention layer - feature fusion layer". Unlike the traditional unidirectional attention model that only focuses on the matching degree of fields with assessment dimensions, this model strengthens the reverse constraint of assessment dimensions on sub-items on field semantics through a bidirectional interaction mechanism, thereby improving the accuracy of semantic mapping in financial scenarios.

[0052] In the input layer construction phase: the input objects are determined to be the field semantic vectors of the risk assessment raw metadata generated in step 14, as well as the sub-item vectors of the user credit status assessment dimension and the user performance capability assessment dimension. The generation process of the field semantic vectors is as follows: extract the field definition text of each field in the risk assessment raw metadata, encode it through a pre-trained language model in the financial field (fine-tuned based on the risk assessment corpus, including high-frequency words in scenarios such as "overdue", "credit granting", and "repayment"), and convert the text into a fixed-dimensional vector (the dimension is set to 300 dimensions in the general implementation, which can be adjusted according to the complexity of the field definition in specific scenarios). Each vector element corresponds to the weight value of a certain semantic feature in the field definition (e.g., in the vector of the "overdue record" field, the feature elements related to "credit default" have higher weights). The generation process for the user creditworthiness assessment dimension sub-item vectors is as follows: Core sub-items of credit assessment are identified (such as "historical overdue payments," "credit score trend," and "guarantee default records," typically set to 5-8 sub-items, expandable in specific scenarios). The descriptive text for each sub-item (e.g., "historical overdue payments: the cumulative number of overdue credit transactions by the user in the past 36 months") is also encoded into a vector of the same dimension using a pre-trained language model in the financial field. Vector elements correspond to the weights of the core assessment elements of the sub-item. The generation process for the user's repayment ability assessment dimension sub-item vectors is similar. Its core sub-items include "average monthly income stability," "debt-to-income ratio," and "scale of realizable assets," which are encoded into vectors of the same dimension as the field semantic vectors. The input layer standardizes these three types of vectors (making the vector magnitude 1), generating a standardized input vector set that the model can directly accept.

[0053] In the design phase of the bidirectional attention layer: This layer contains two parallel attention calculation units—the "Field-Credit" attention unit and the "Field-Performance" attention unit, each implementing bidirectional attention interaction. Taking the "Field-Credit" attention unit as an example, its processing logic is as follows: First, the field semantic vector is used as the query vector (Q), and the credit status assessment dimension sub-item vector is used as the key vector (K) and value vector (V). The first-stage attention weight (reflecting the matching degree of the field to the credit sub-item) is calculated using the attention formula. Then, the credit status assessment dimension sub-item vector is used as the query vector (Q'), and the field semantic vector is used as the key vector (K') and value vector (V'). The second-stage attention weight (reflecting the reverse constraint degree of the credit sub-item on the field) is calculated. The weights of the two stages are merged according to a preset ratio (the first stage weight accounts for 0.6 and the second stage weight accounts for 0.4 in general implementations, because field semantics need to be adapted to the assessment dimension first in financial scenarios) to obtain a bidirectional attention weight matrix. The rows of this matrix represent field semantic vectors, the columns represent user credit status assessment dimension sub-item vectors, and the matrix element values ​​represent the strength of the bidirectional semantic association between the two. The “Field-Performance” attention unit uses the same logic to generate a bidirectional attention weight matrix of field semantic vectors and performance capability assessment dimension sub-item vectors. The outputs of the two units together constitute the bidirectional attention feature matrix.

[0054] In the feature fusion layer construction stage: the bidirectional attention feature matrix is ​​residually connected to the original input vector group (preserving basic semantic information and avoiding excessive weakening of the original features by the attention mechanism). Feature compression and nonlinear transformation are performed through two fully connected layers (the first layer reduces the feature dimension to 150 dimensions, and the second layer maintains the same dimension as the input vector), generating an enhanced semantic vector group that integrates bidirectional attention information. This includes enhanced field semantic vectors, enhanced credit status assessment dimension sub-item vectors, and enhanced performance capability assessment dimension sub-item vectors. This enhanced semantic vector group not only preserves the original semantic features but also incorporates the contextual association information brought by bidirectional attention, solving the problem of semantic misalignment between fields and assessment dimensions in traditional models (e.g., the "realizable assets" field may only match the credit dimension in traditional models, while this model strengthens its association with the performance capability dimension through bidirectional attention).

[0055] Finally, the input layer receives and standardizes the original vectors, and then the bidirectional attention layer realizes the bidirectional semantic interaction between the fields and the evaluation dimensions. Finally, the feature fusion layer generates an enhanced semantic vector group, which provides a more accurate semantic feature basis for the calculation of cosine similarity in step 22. The overall architecture is particularly suitable for the semantic complexity of "one word with multiple meanings" and "multiple words with one meaning" in the risk assessment scenario of financial users.

[0056] Optionally, step 2 specifically includes: Step 22: Calculate the first cosine similarity between the field semantic vector and the user credit status assessment dimension sub-item vector, and the second cosine similarity between the field semantic vector and the user credit status assessment dimension sub-item vector, respectively, through the dual-path parallel computing module of the hidden layer of the semantic mapping model.

[0057] Preferably, the specific implementation process of step 22 is as follows: First, the processing object is determined to be the enhanced semantic vector group (including the enhanced field semantic vector, the enhanced credit status assessment dimension sub-item vector, and the enhanced performance capability assessment dimension sub-item vector) generated in step 21 by fusing bidirectional attention information. Based on the independence and correlation of the "credit-performance" dual dimensions in the financial user risk assessment scenario, a dual-path parallel computing module is designed to realize the efficient calculation and scenario-based optimization of the two types of cosine similarity.

[0058] In the dual-path parallel computing module construction phase: This module includes a credit dimension calculation branch and a performance dimension calculation branch. The two branches have symmetrical structures but independent parameters, respectively adapting to the semantic characteristics of the two types of evaluation dimensions. Each branch consists of a "vector alignment unit - similarity calculation unit - scene weight adjustment unit". The vector alignment unit is responsible for ensuring the dimensional consistency and numerical range compatibility of the input vectors. It receives the enhanced field semantic vectors (set to M, with a dimension of D) and the corresponding evaluation dimension sub-item vectors (K sub-items for the credit dimension and L sub-items for the performance dimension, both with a dimension of D). It adjusts the vectors to the same dimension through zero padding or truncation (in the actual scenario, the dimension consistency has been ensured through step 21). Then, it normalizes the vector element values ​​to the range of [-1,1] to generate the aligned credit dimension vector group (containing M field semantic vectors and K user credit status evaluation dimension sub-item vectors) and the aligned performance dimension vector group (containing M field semantic vectors and L user performance capability evaluation dimension sub-item vectors).

[0059] In the first cosine similarity calculation stage (credit dimension calculation branch): the similarity calculation unit receives the aligned credit dimension vector group and uses the cosine similarity formula to calculate the original similarity value between each field semantic vector and each credit status assessment dimension sub-item vector. Specifically, for the i-th field semantic vector (i=1 to M) and the j-th user credit status assessment dimension sub-item vector (j=1 to K), the cosine value of the angle between them is calculated to obtain the original similarity s_ij. These original similarity values ​​constitute the initial credit similarity matrix, where the rows of the matrix represent field semantic vectors, the columns represent user credit status assessment dimension sub-item vectors, and the matrix element s_ij represents the semantic correlation between the i-th field semantic vector and the j-th user credit status assessment dimension sub-item vector. Subsequently, the scenario weight adjustment unit introduces the weight coefficients of the credit dimension sub-items (based on the importance preset of each sub-item in the financial risk assessment model, such as the weight of "historical overdue number" being set to 0.3, the weight of "credit score change trend" being set to 0.25, and the sum being 1). Each element s_ij in the initial credit similarity matrix is ​​multiplied by the weight coefficient of the corresponding sub-item to obtain the adjusted first cosine similarity matrix. This matrix reflects both the semantic relevance and the difference in scenario importance.

[0060] In the second cosine similarity calculation stage (performance dimension calculation branch): the same logic as the credit dimension calculation branch is used, but parameters are adapted to the characteristics of the performance capability assessment scenario. The similarity calculation unit receives the aligned performance dimension vector group, calculates the original similarity t_il between the semantic vector of the i-th field and the sub-item vector of the l-th user performance capability assessment dimension (l=1 to L), and generates an initial performance similarity matrix (rows represent field semantic vectors, columns represent sub-item vectors of user performance capability assessment dimension, and element t_il is the original semantic relevance). The scenario weight adjustment unit introduces the weight coefficients of the performance dimension sub-items (e.g., the weight of "debt-to-income ratio" is set to 0.3, the weight of "quantifiable asset size" is set to 0.25, and the sum is 1), multiplies each element t_il in the initial performance similarity matrix by the weight coefficient of the corresponding sub-item, and obtains the adjusted second cosine similarity matrix. The core difference between this matrix and the first cosine similarity matrix lies in the scenario adaptability of the sub-item weight system—the performance dimension focuses more on the user's current financial capability, while the credit dimension focuses more on historical behavior records.

[0061] In the parallel computing result fusion stage: the dual-path parallel computing module ensures the time consistency of the two computing paths through a synchronization mechanism, and labels the first and second cosine similarity matrices with dimensions (adding "credit dimension" and "performance dimension" labels respectively), and then integrates them into a two-dimensional similarity set. Each element in this set contains four key pieces of information: field ID, assessment dimension type (credit / performance), sub-item name, and adjusted cosine similarity value. This not only preserves the original calculation results, but also strengthens the semantic association signals of core sub-items in financial risk assessment through scenario weight adjustment.

[0062] Finally, the first and second cosine similarity matrices output by the dual-path parallel computing module serve as the direct processing objects for "filtering mapping pairs that exceed the threshold" in step 23. Their scenario-adjusted similarity values ​​solve the mismatch problem of "semantic matching but insufficient importance" in the financial scenario caused by traditional cosine similarity, thus improving the rationality of subsequent mapping pair filtering.

[0063] Optionally, step 2 specifically includes: step 23: filtering credit mapping pairs whose first cosine similarity exceeds the credit threshold and performance mapping pairs whose second cosine similarity exceeds the performance threshold.

[0064] Preferably, the specific implementation process of step 23 is as follows: First, the processing objects are determined to be the first cosine similarity matrix (the correlation between the field and the sub-item vector of the user credit status assessment dimension) and the second cosine similarity matrix (the correlation between the field and the sub-item vector of the user's performance capability assessment dimension) generated in step 22. Considering the characteristics of the threshold setting in the financial user risk assessment scenario, which needs to take into account both rigor and flexibility, a three-order processing mechanism of "dynamic threshold generation - double-layer screening - conflict arbitration" is adopted to achieve accurate screening of mapping pairs.

[0065] In the dynamic threshold generation stage: based on the statistical characteristics of the first and second cosine similarity matrices, credit thresholds and performance thresholds are generated respectively. For the credit threshold, the distribution characteristics (including mean, standard deviation, and quartiles) of all elements in the first cosine similarity matrix are first calculated. Then, combined with the error tolerance requirements of the credit dimension in financial risk assessment (credit assessment requires higher rigor to avoid omitting high-risk associations), the calculation method of "lower quartile + dynamic offset" is adopted—the dynamic offset is positively correlated with the dispersion of matrix elements (high dispersion results in a small offset, avoiding over-screening; low dispersion results in a large offset, strengthening discrimination), generating the initial credit threshold. For the performance threshold, the same distribution characteristic calculation method is used, but based on the characteristic that performance capability assessment pays more attention to data integrity, the dynamic offset is adjusted to be positively correlated with the central tendency of matrix elements (high central tendency results in a small offset, retaining more potential associations), generating the initial performance threshold. Subsequently, a threshold range preset by domain experts was introduced (the general range for credit threshold was set to 0.6-0.75, and the general range for performance threshold was set to 0.55-0.7). The initial thresholds were constrained within this range to obtain the final credit threshold and performance threshold, ensuring that the thresholds conform to both data statistical characteristics and scenario business rules.

[0066] In the two-layer screening stage: The first layer is numerical screening, which traverses each element in the first cosine similarity matrix (the similarity value between the field semantic vector and the sub-item vector of the user credit status assessment dimension), and marks elements exceeding the credit threshold as candidate credit mapping pairs, recording their field ID, credit sub-item name and similarity value, generating a list of candidate credit mapping pairs; similarly, it traverses the second cosine similarity matrix, and marks elements exceeding the performance threshold as candidate performance mapping pairs, generating a list of candidate performance mapping pairs. The second layer is semantic verification, which extracts the cross-domain association index code of the fields in each mapping pair (from step 13) for the candidate credit mapping pair list, and checks whether cross-domain fields with the same index code are all mapped to the same credit sub-item (e.g., "User ID" and "Account ID" belong to the same index code G001, if the former is mapped to the "Identity Authenticity" sub-item and the latter is mapped to the "Consistency of Historical Behavior" sub-item, it is determined to be a semantic conflict); the same logic is used to verify the cross-domain semantic consistency of the candidate performance mapping pair list. Candidate mapping pairs that pass semantic verification are retained, generating a list of verified credit mapping pairs and a list of verified performance mapping pairs. This list resolves the cross-domain semantic inconsistency problem that may result from relying solely on numerical screening.

[0067] During the conflict arbitration phase: For fields that exist simultaneously in both the credit mapping pair list and the performance mapping pair list (the same field may match two dimensions simultaneously), a conflict arbitration mechanism is initiated. This mechanism arbitrates based on the matching degree between the core business attributes of the field (extracted from the field definition, such as "credit default record" for "number of overdue payments" and "proof of repayment ability" for "monthly income") and the evaluation dimensions—calculating the thematic similarity between the core attributes of the field and the credit and performance dimensions (using the cosine similarity calculation method in step 22), retaining the dimension mapping relationship with higher thematic similarity; if the thematic similarity difference is less than a preset threshold (set to 0.1 in general implementation), the dual-dimensional mapping relationship is retained and marked as a "cross-dimensional associated field" (such as "guarantee record" which is associated with both credit status and performance ability). After arbitration, a final credit mapping pair list and a final performance mapping pair list are generated, where each mapping pair contains a field ID, the name of the corresponding evaluation dimension sub-item, a similarity value, a cross-domain association index code, and an arbitration result identifier.

[0068] Ultimately, the selected credit mapping pairs and performance mapping pairs are processed as the "add dimension labels" in step 24. They adapt to scenario characteristics through dynamic thresholds, ensure semantic consistency through two-layer screening, and resolve multi-dimensional mapping contradictions through conflict arbitration. Unlike the traditional fixed threshold screening method, this significantly improves the accuracy and rationality of mapping pairs in financial scenarios.

[0069] Optionally, step 2 specifically includes: step 24: adding a "credit status - sub-item name" label to the credit mapping pair and a "performance capability - sub-item name" label to the performance mapping pair through the output layer of the semantic mapping model, and assigning a cross-domain association index code to generate risk assessment annotation metadata that simultaneously contains dimension labels and data domain affiliation labels.

[0070] Preferably, the specific implementation process of step 24 is as follows: First, the processing objects are determined to be the final credit mapping pair list and the final performance mapping pair list generated in step 23 (including field ID, corresponding assessment dimension sub-item name, similarity value, cross-domain association index code and arbitration result identifier), and the data domain attribution identifier in the basic metadata fields generated in step 13. In view of the requirements for the refinement and traceability of metadata tags in the financial user risk assessment scenario, a three-level processing logic of "layered tag embedding - dynamic binding of index code - full-domain verification integration" is adopted to generate risk assessment label metadata that has both semantic dimension and data domain attributes.

[0071] In the hierarchical label embedding stage: Based on the final credit mapping pair list, a hierarchical label "Credit Status - Sub-item Name" is added to the fields in each credit mapping pair. This label has a three-layer structure: the main label is "Credit Status," used to identify the major category of the assessment dimension; the sub-label is the specific sub-item name (such as "Number of Historical Overdue Payments" or "Guarantee Default Records"), corresponding to the detailed assessment items of the credit dimension; the confidence label is the normalized result of the similarity value in step 23 (linearly transforming the similarity value to a score range of 0-100), used to quantify the reliability of the match between the label and the field. For example, the "Overdue Records" field matches the sub-item "Credit Status - Number of Historical Overdue Payments" with a similarity value of 0.78, and its hierarchical label is "Credit Status [Main Label] - Number of Historical Overdue Payments [Sub Label] - 78 [Confidence Label]". Similarly, based on the final performance mapping pair list, a hierarchical label of "performance capability - sub-item name" is added to the fields in each performance mapping pair. The structure is consistent with the credit label. For example, the label corresponding to the "monthly income" field is "performance capability [main label] - average monthly income stability [sub-label] - 82 [confidence label]". For the "cross-dimensional related fields" marked in step 23, two types of hierarchical labels are embedded at the same time to form a composite label set to ensure the semantic integrity of the fields in multi-dimensional evaluation.

[0072] During the dynamic binding phase of the index code: Extract the cross-domain association index code for each field (from step 13), and generate an extended index code by combining it with the sub-item name in the hierarchical label. The extended index code adopts a three-part structure of "basic index code + dimension identifier + sub-item code"—the basic index code retains the original cross-domain association index code (e.g., G001), the dimension identifier uses "C" to represent credit status and "P" to represent repayment ability, and the sub-item code is an abbreviation of the sub-item name (e.g., "historical overdue number" is abbreviated as YQC), for example, G001-C-YQC. For cross-dimensional association fields, generate two extended index codes (e.g., G002-C-DJB and G002-P-FZY, corresponding to "guarantee record" in the credit dimension and "debt pressure" in the repayment dimension, respectively). The extended index code is bound and stored with the original cross-domain association index code of the field to form an index code mapping table (recording the correspondence between the basic index code, the extended index code, and the field ID). This table not only retains the original information of cross-domain semantic association, but also strengthens the relevance of the evaluation dimensions through the extended index code, providing a multi-dimensional retrieval basis for the construction of the lineage link in step 3.

[0073] In the full-domain verification and integration phase: the fields with embedded hierarchical tags are integrated with the corresponding data domain affiliation identifiers (from step 13) to generate a preliminary labeled metadata set containing "field core attributes (definition, type, etc.) - hierarchical tag set - data domain affiliation identifier - extended index code". Two types of verifications are initiated for this set: First, tag integrity verification, checking whether each field contains at least one dimension tag (credit or performance). If there are unlabeled fields (because the similarity does not reach the threshold), they are marked as "fields to be supplemented for evaluation" and associated with their cross-domain index codes, prompting a manual review. Second, intra-domain tag consistency verification, for fields with the same extended index code within the same data domain, the sub-item names of their hierarchical tags must be consistent (e.g., fields with extended index codes G003-C-SFZ in the user basic information domain must all be associated with the "credit status - identity authenticity" sub-item). If they are inconsistent, tag correction is triggered (based on the tag of the index code in the external associated domain, because third-party data tags are more authoritative). After verification, the initial set of labeled metadata is grouped according to the data domain affiliation identifier, generating user basic information domain labeled metadata group, behavioral feature domain labeled metadata group, and external association domain labeled metadata group, which are finally merged into risk assessment labeled metadata.

[0074] This process differs from traditional single-label annotation methods. It achieves refined descriptions of assessment dimensions through hierarchical labels, strengthens cross-domain and cross-dimensional dual associations through extended index codes, and ensures label consistency through scenario-based verification mechanisms. It is particularly suitable for the multi-dimensional interpretation needs of data semantics in financial risk assessment. The generated risk assessment labeled metadata serves as the core input for the "tracing data lineage link construction" in step 3. Its multi-layered labels and extended index codes provide a structured foundation for full-domain data association analysis.

[0075] Optionally, step 3 specifically involves: using risk assessment annotation metadata as the core node, tracing forward to generate intra-domain lineage sub-links, and tracing backward to generate application-layer lineage sub-links; and generating a risk assessment metadata lineage map containing the data flow relationship across the entire domain and the inter-domain relationship based on the intra-domain lineage sub-links and the application-layer lineage sub-links.

[0076] Optionally, step 3 specifically includes the following steps: Step 31: Taking the risk assessment annotation metadata as the core node, trace back to the data collection source, record the collection rules, format conversion logs and internal circulation paths in each data domain, and generate internal lineage sub-links.

[0077] Preferably, the specific implementation process of step 31 is as follows: First, the processing object is determined to be the risk assessment annotation metadata (including core field attributes, hierarchical tag set, data domain affiliation identifier and extended index code) generated in step 24. In view of the multi-node and multi-form characteristics of data flow within the data domain in the financial user risk assessment scenario, a three-level processing architecture of "intra-domain node topology modeling - reverse tracing engine - full-link feature encapsulation" is adopted to generate the traceable intra-domain lineage sub-link.

[0078] In the domain-specific node topology modeling phase: Risk assessment metadata is divided into three domain subsets based on data domain affiliation identifiers (user basic information domain, behavioral feature domain, and external association domain). For each subset, the storage architecture and processing node types for the corresponding data domain are defined—the user basic information domain includes an identity database, account core system, and information verification nodes; the behavioral feature domain includes a transaction log server, behavioral analysis engine, and feature extraction nodes; and the external association domain includes third-party data interfaces, credit data caching nodes, and association strength calculation modules. A unique node identifier is assigned to each node (e.g., the identity database in the user basic information domain is labeled UDB-001), and standard interaction relationships between nodes are defined (e.g., "data extraction," "format conversion," "verification passed," "storage backup"), constructing a domain-specific node topology graph. In this topology graph, nodes represent data processing or storage units, edges represent data flow directions, and edge attributes indicate flow trigger conditions (e.g., "incremental synchronization at 3 AM daily"), providing a path framework for reverse tracing.

[0079] During the reverse tracing engine operation phase: Starting with each field in the risk assessment annotation metadata, the reverse tracing within the domain is initiated. The engine first parses the source system identifier of the field (from the basic metadata field in step 12) to locate its final storage node in the domain node topology graph (e.g., the final node for the "Monthly Income" field is the feature storage node BFS-003 of the behavioral feature domain). Starting from this node, the node interaction log is queried in reverse (recording the data inbound source, processing time, and operator) to obtain the information of the next-level node (e.g., the upstream of BFS-003 is the behavioral analysis engine BAE-002). For each traceability node, three types of core information are extracted: First, the collection rule adaptation record, which associates the domain-specific filtering rules in step 113 (such as the time window filtering parameter "last 90 days" in the behavior feature domain) and records the execution results of the rules in the node (such as actually filtering 15% of invalid behavior data); second, the format conversion log, including the definition mapping before and after field-level conversion (such as "transaction amount" from "string" to "floating point"), the algorithm used for conversion (such as the outlier truncation algorithm in numerical cleaning) and the conversion success rate; third, the domain flow path characteristics, marking the key node types in the path (such as "original data node", "cleaning node", "aggregation node") and the transmission protocol between nodes (such as the encrypted transmission protocol AES-256 in the user basic information domain). When tracing back to the original collection node in the data domain (such as the third-party interface node API-001 in the external related domain), the engine stops tracing and generates a single-field reverse tracing chain.

[0080] In the end-to-end feature encapsulation stage: features are integrated into the reverse tracing chain of each field to generate intra-domain lineage sub-link units. This unit contains five parts of structured information: link identifier (composed of data domain code + field ID, such as "U-USER001" representing the "User ID" field of the user basic information domain); node sequence (node ​​identifiers and node types arranged in tracing order); rule and transformation set (associated collection rules, format transformation logs, and corresponding timestamps); data form change record (records every structural change of the field from its original form to its current form, such as unstructured credit report text → semi-structured JSON field → structured "number of overdue payments" value); link integrity score (calculated based on the integrity of node logs, with a maximum score of 100 points. Missing key transformation logs will deduct corresponding points, such as deducting 15 points for missing encryption algorithm records). All field lineage sub-link units within the same data domain are grouped by extended index codes (associating semantically related fields) to form user basic information domain lineage sub-links, behavioral feature domain lineage sub-links, and external association domain lineage sub-links. Each group of links achieves horizontal association within the domain by associating fields through index codes.

[0081] This process differs from traditional lineage tracing methods that merely record data flow paths. It clarifies intra-domain processing boundaries through node topology modeling, integrates rules and transformation details through a reverse tracing engine, and quantifies lineage integrity through end-to-end feature encapsulation. This approach is particularly well-suited to the auditability requirements of financial scenarios. The generated intra-domain lineage sub-links serve as the foundation for "inter-domain lineage sub-link construction" in step 32. The node interaction relationships and transformation rules they contain provide intra-domain contextual information for cross-domain data association.

[0082] Optionally, step 3 specifically includes: Step 32: Based on the data domain affiliation label and cross-domain association index code, track the transmission interface, conversion algorithm and verification rules of risk assessment annotation metadata between the user basic information domain and the behavioral feature domain, and between the behavioral feature domain and the external association domain, and generate inter-domain lineage sub-links.

[0083] Preferably, the specific implementation process of step 32 is as follows: First, the processing objects are determined to be the risk assessment annotation metadata (including data domain affiliation tags, cross-domain association index codes, and extended index codes) generated in step 24 and the intra-domain lineage sub-links (including intra-domain node topology and data flow paths) generated in step 31. In view of the security and semantic consistency requirements of inter-domain data interaction in the financial user risk assessment scenario, a four-level processing logic of "cross-domain association field grouping - inter-domain interface trajectory tracking - scenario-based analysis of conversion algorithms - closed-loop extraction of verification rules" is adopted to generate inter-domain lineage sub-links containing complete inter-domain interaction details.

[0084] In the cross-domain association field grouping stage: using the cross-domain association index code in the risk assessment annotation metadata as the core grouping basis, fields with the same cross-domain association index code in different data domains are grouped into the same cross-domain field group. For example, the field group corresponding to the cross-domain association index code "G001-User Identifier Association" includes "User ID" (data domain affiliation label "UBI-User Basic Information Domain") in the User Basic Information Domain, "Account ID" (label "BHD-Behavioral Feature Domain") in the Behavioral Feature Domain, and "Document Number" (label "ERD-External Linkage Domain") in the External Association Domain. For each cross-domain field group, the core business attributes of the field are supplemented (extracted from the field definition, such as "User Identifier Class", "Credit Score Class", "Performance Capability Class") to generate a cross-domain field grouping table. This table clarifies the core carrier of data association between domains, providing a target object for subsequent inter-domain tracking.

[0085] During the inter-domain transmission interface tracing phase: For each cross-domain field group, locate the "inter-domain output node" (i.e., the final node where data flows out of this domain) of each field in its respective data domain from the intra-domain lineage sub-links in step 31. Examples include the "cross-domain data gateway node UBG-001" in the user basic information domain and the "third-party data interaction node BIG-002" in the behavioral characteristics domain. By querying the interaction logs of the inter-domain output nodes, extract complete information about the inter-domain transmission interface to form an inter-domain transmission interface information table. This table contains four categories of scenario-based information: First, basic interface attributes (interface name, interface type, such as "internal cross-domain API interface" or "third-party HTTPS interface"; interfaces between the user basic information domain and the behavioral characteristic domain are mostly internal interfaces, while interfaces between the behavioral characteristic domain and the external related domain are mostly third-party interfaces); second, interface communication parameters (transmission protocol, such as TCP for internal interfaces and HTTPS for third-party interfaces; request timeout, generally set to 30-60 seconds, and 30 seconds for highly sensitive financial data interfaces to reduce the risk of leakage; data compression format, such as gzip); third, interface security configuration (whether the inter-domain key negotiation mechanism in step 112 is enabled, encryption algorithm type, such as AES-256; whether cross-domain access token verification is required, and verification frequency); and fourth, interface call records (number of calls, success / failure rate, and average response time in the last 30 days). This table is bound to the cross-domain field grouping table to specify the inter-domain transmission interface corresponding to each cross-domain field group.

[0086] In the inter-domain data conversion algorithm analysis stage: Addressing the format and semantic differences between different data domain fields in the cross-domain field group, details of the inter-domain data conversion algorithm are extracted from the processing logs of the inter-domain output nodes. Analysis is categorized into two types based on conversion type: First, format conversion algorithms, such as converting the user basic information field "User ID" (a 10-digit numeric string) to the behavioral feature field "Account ID" (prefix "BH_" + 10 digits, i.e., "BH_1234567890"). This involves analyzing the specific logic of the algorithm (string concatenation rules, bit verification logic), the tool libraries the algorithm depends on (such as the financial data format conversion toolkit), and the format specifications after conversion (consistent with the standardized format in step 12). Second, semantic mapping conversion algorithms, such as the external association field "Third-Party Credit Rating" (…). The "AAA / AA / A / B / C" scores are converted into the behavioral feature domain "Internal Credit Score" (corresponding scores of 850-950 / 750-849 / 650-749 / 550-649 / 450-549). The semantic mapping table is parsed (clarifying the correspondence between third-party ratings and internal scores), the mapping weight adjustment logic is implemented (e.g., adjusting the mapping coefficient based on the third-party institution's qualification level, setting the coefficient to 1.0 for institutions with high qualifications and 0.95 for those with medium qualifications), and the correction rules for the conversion results are established (if a third-party rating is missing, the average score of users of the same type is used to fill the gap). The parsed conversion algorithm information is encapsulated into "Inter-domain Conversion Algorithm Units" and associated with a cross-domain field grouping table to ensure that each field's format / semantic differences have a corresponding algorithmic origin.

[0087] In the inter-domain data verification rule extraction stage: extract data verification rules for cross-domain field groups from the receiving node logs of the inter-domain transmission interface (the first node where data flows into the target domain) to form an inter-domain verification rule set that adapts to the data compliance requirements of financial scenarios. The rule types include: First, format compliance verification (checking whether the field format conforms to the standardized specifications of the target domain, such as whether "User ID" conforms to the format "BH_+10 digits" after being converted to "Account ID". If it does not conform, the interface will return "format error"); Second, data integrity verification (checking whether the fields transmitted across domains contain required subfields. For example, when transmitting "guarantee records" from external related domains, it must contain three subfields: "guarantee amount", "guarantee period", and "guarantee status". If they are missing, the data will be rejected); Third, data consistency verification (checking whether the core values ​​of fields in different domains within the same cross-domain field group match. For example, whether the user identity identifier corresponding to "User ID" in the user basic information domain is consistent with that in the behavioral feature domain "Account ID". This is verified by querying the user identity mapping database. If they are inconsistent, they will be marked as "pending verification"); Fourth, data timeliness verification (checking whether the interval between the generation time and the reception time of cross-domain transmitted data exceeds a preset threshold. For example, "credit data" from external related domains must be transmitted within 24 hours after generation. If it exceeds the time limit, it must be retrieved again. Record the execution results of each verification rule (verification pass rate and failure reason distribution over the past 30 days) to form an "inter-domain verification rule unit".

[0088] Finally, the cross-domain field grouping table, inter-domain transmission interface information table, inter-domain conversion algorithm unit, and inter-domain verification rule unit are integrated and encapsulated according to the structure of "cross-domain association index code - inter-domain path (e.g., UBI→BHD→ERD) - transmission interface information - conversion algorithm details - verification rules and results" to generate the inter-domain lineage sub-link unit corresponding to each cross-domain field group. All units are classified according to the cross-domain association index code to form a complete inter-domain lineage sub-link. This sub-link not only clarifies the flow path of inter-domain data but also includes core technical details such as interfaces, algorithms, and verification. It differs from the traditional simple link that only records "domain A→domain B" and provides a refined inter-domain association basis for the topology fusion in step 34, while meeting the compliance requirements of financial scenarios for auditable and traceable inter-domain data interaction.

[0089] Optionally, step 3 specifically includes: Step 33: Tracing back the application nodes of risk assessment annotation metadata in the risk assessment model, recording the data input-output relationship, model parameter association and the weight of the impact of assessment results, and generating application layer lineage sub-links.

[0090] Optionally, step 3 specifically includes: step 34: performing topology fusion on intra-domain lineage sub-links, inter-domain lineage sub-links and application layer lineage sub-links to generate a risk assessment metadata lineage map containing the data flow relationship across the entire domain.

[0091] Preferably, the specific implementation process of step 34 is as follows: First, the processing objects are determined to be the intra-domain lineage sub-links generated in step 31, the inter-domain lineage sub-links generated in step 32, and the application layer lineage sub-links generated in step 33. In view of the complexity and correlation of the whole-domain data flow in the financial user risk assessment scenario, a four-order processing framework of "link standardization adaptation - associated node anchoring - topology relationship fusion - graph feature enhancement" is adopted to generate a risk assessment metadata lineage graph covering the entire process of "data acquisition - intra-domain processing - cross-domain transmission - model application".

[0092] In the link standardization and adaptation phase: the format and semantics of the three types of lineage sub-links are unified. First, the core elements of each sub-link are extracted—the "intra-domain node sequence, rules and transformation set" for intra-domain lineage sub-links, the "cross-domain association index code, transmission interface information, and transformation algorithm details" for inter-domain lineage sub-links, and the "model application node topology, data input and output mapping, and evaluation result impact weight" for application layer lineage sub-links. Then, a standardized description template is defined to map the elements of different sub-links to unified fields: node information is unified as "unique node identifier, node type, and data domain / model level"; relationship information is unified as "source node identifier, target node identifier, relationship type (such as "intra-domain flow", "cross-domain transmission", "model application"), and relationship strength value (calculated based on data interaction frequency, such as 0.8-1.0 for more than 1000 interactions per day, 0.5-0.7 for 100-1000 interactions, and 0.1-0.4 for less than 100 interactions)"; attribute information is unified as "timestamp range, operation log summary, and compliance verification result". Through standardized adaptation, three types of standardized lineage sub-links are generated, eliminating description differences between different links and laying the foundation for subsequent integration.

[0093] In the node anchoring stage: Based on the node identifiers and cross-domain association index codes in the standardized lineage sub-links, the associated nodes between different sub-links are identified, and a global node association matrix is ​​constructed. The rows and columns of this matrix are node identifiers in all sub-links, and the matrix element values ​​represent the association strength between two nodes (0 indicates no association, and values ​​between 0 and 1 indicate a close association). Specifically, the implementation is as follows: First, intra-domain and inter-domain node association: the "inter-domain output node" (e.g., UBG-001 in the user basic information domain) of intra-domain related sub-links is matched with the "transmission interface starting node" of inter-domain related sub-links. If the node identifiers match, the association strength is set to 1.0 (strong association). Second, inter-domain and application layer node association: the "transmission interface ending node" of inter-domain related sub-links is matched with the "initial access node" (e.g., credit dimension data access node) of application layer related sub-links through cross-domain association index codes. If the index codes are the same, the association strength is set to 0.9 (higher association). Third, intra-link node association within the same type of link: for example, in a continuous node sequence (e.g., A→B→C) within an intra-domain related sub-link, the association strength between A and B, and B and C in the matrix is ​​set to 0.8-0.9 (based on flow frequency). The generated global node association matrix clarifies the association relationships between nodes in different links, providing a basis for topology fusion.

[0094] In the topology fusion phase: Based on the global node association matrix, a strategy of "core node priority fusion - association relationship hierarchical mapping - conflict relationship arbitration" is adopted to integrate three types of standardized lineage sub-links. First, core nodes are identified—field nodes in the risk assessment annotation metadata (as the core carrier of data flow), core calculation layer nodes of the model (as the core processing unit of the application layer), and cross-domain transmission interface nodes (as the core hub of inter-domain interaction)—and these nodes are used as the starting point for fusion. Then, fusion is carried out layer by layer in the order of "intra-domain links → inter-domain links → application layer links": the nodes and relationships of intra-domain lineage sub-links are loaded into the fusion space, then the inter-domain lineage sub-links are connected through the anchoring results of association nodes, and finally the application layer lineage sub-links are connected to form a preliminary fusion topology. For conflicts arising during the fusion process (such as inconsistent relationship types or strength values ​​between a pair of nodes in different links), a "scenario-based arbitration rule" is adopted: financial compliance-related nodes (such as credit data transmission nodes) are described according to the relationship description of inter-domain links (because inter-domain transmission has strict compliance records); model computation-related nodes (such as feature engineering nodes) are described according to the relationship description of application layer links (because model logs are more accurate); and ordinary data nodes are described according to the link description with the higher relationship strength value. Through topological relationship fusion, a global lineage topology graph containing all nodes and their relationships is generated.

[0095] In the graph feature enhancement stage: Enhancement features specific to the financial risk assessment scenario are added to the global kinship topology graph to improve its analytical value. First, data sensitivity labels are added. Based on the hierarchical labels of fields (e.g., "Credit Status - Historical Overdue Counts" is highly sensitive, "Responsibility Ability - Average Monthly Consumption" is moderately sensitive), a sensitivity level (high / medium / low) is assigned to each node, and the data anonymization processing method (e.g., "encrypted transmission" or "transmission after anonymization") is marked on the relationships between nodes. Second, a time decay factor is added. The decay coefficient of relationship strength is calculated based on the timestamp of data flow (e.g., 1.0 for relationships within 30 days, 0.8 for 30-90 days, and 0.5 for over 90 days), dynamically adjusting the element values ​​in the global node association matrix. Third, compliance verification markers are added. The verification results recorded in steps 31-33 (e.g., intra-domain conversion power, inter-domain verification pass rate, model parameter compliance) are mapped to the corresponding nodes and relationships, using different colors to indicate the verification passed (green), pending verification (yellow), and failed (red) status. The enhanced global lineage topology map retains the technical details of data flow while incorporating the business characteristics of financial scenarios.

[0096] Finally, the enhanced global lineage topology map is indexed hierarchically according to "data domain - processing stage - business dimension": the data domain dimension includes user basic information domain subgraphs, behavioral feature domain subgraphs, and external association domain subgraphs; the processing stage dimension includes collection stage subgraphs, transformation stage subgraphs, and application stage subgraphs; and the business dimension includes credit status assessment subgraphs and performance capability assessment subgraphs. Through multi-dimensional indexing and visualization configuration, a complete risk assessment metadata lineage map is generated. This map differs from traditional single-dimensional lineage maps, achieving deep integration of the technical chain and business dimension, and providing a panoramic data flow view for the extraction of global association rules in step 4.

[0097] Optionally, step 4 specifically involves: extracting intra-domain association rules, inter-domain association rules, and application-layer association rules from the risk assessment metadata lineage map; and prioritizing the extracted intra-domain association rules, inter-domain association rules, and application-layer association rules by adopting the following order: application-layer association rules have higher priority than intra-domain association rules, intra-domain rules have higher priority than inter-domain rules, and direct association rules have higher priority than indirect association rules, thereby constructing a full-domain association rule library to generate a full-domain data source asset map.

[0098] Preferably, the specific implementation process for extracting intra-domain association rules, inter-domain association rules, and application-layer association rules from the risk assessment metadata lineage graph is as follows: First, the processing object is determined to be the risk assessment metadata lineage graph (including intra-domain subgraphs, inter-domain subgraphs, application-layer subgraphs, and multi-dimensional indexes) generated in step 34. Considering the characteristic differences of association rules at different levels in the financial user risk assessment scenario, a four-order unified extraction framework of "subgraph targeted splitting - core element extraction - rule pattern recognition - scenario-based rule encapsulation" is adopted to accurately extract the three types of association rules respectively, ensuring that the rules are highly adapted to the scenario requirements.

[0099] I. Implementation of Intra-Domain Association Rule Extraction

[0100] First, subgraphs within the domain (including subgraphs of user basic information, behavioral characteristics, and external associations) are extracted from the risk assessment metadata lineage graph. Each subgraph within the domain contains core information such as "intradomain node sequence, rule and transformation set, and data form change record".

[0101] The first step is to locate the key interactive node pairs in the subgraph within the domain (i.e., combinations of nodes with direct data flow relationships, such as "identity database node → format conversion node" and "behavior log node → feature extraction node"), and extract the flow triggering conditions for each node pair—obtain the scenario-based conditions that trigger data flow from the node interaction logs (e.g., the triggering condition for "identity database node → format conversion node" in the user basic information domain is "incremental data synchronization completed at 2 AM every day", and the triggering condition for "behavior log node → feature extraction node" in the behavior feature domain is "single log file size exceeds 100MB"), and generate a list of triggering conditions within the domain.

[0102] The second step is to extract the domain-specific data processing dependency rules based on the "rules and transformation sets"—analyzing the pre-processing requirements that must be met during the flow of each node pair (e.g., before the "format conversion node" processes the "user ID" field, it must first complete the "empty value filling" process, and the filling rule is "using the default prefix of the user ID in the same region + random serial number"; before the "feature extraction node" extracts the "login frequency" feature, it must first complete the "invalid login record filtering", and the filtering rule is "removing records whose IP address is located outside the country and whose login duration is less than 3 seconds"), and generating a list of domain-specific dependency rules;

[0103] The third step is to extract the domain format constraint rules by combining the "data form change record"—clarifying the format consistency requirements of the same field during the flow of data within the domain (e.g., the "date of birth" field in the user basic information domain, after being converted from the "YYYY / MM / DD" format of the "identity database node" to the "YYYY-MM-DD" format through the "format conversion node", all subsequent domain nodes must maintain this format, and reverse conversion or custom format is not allowed), and generate a list of domain format constraint rules;

[0104] Finally, the list of triggering conditions, the list of dependent rules, and the list of format constraint rules within the domain are integrated according to the structure of "node pair identifier - rule type - rule content - applicable scenario description" and encapsulated into a domain-related rule unit (e.g., "UBI-UDB001→UBI-FT001 [node pair identifier] - triggering condition rule [rule type] - daily incremental data synchronization completed at 2 AM [rule content] - applicable to daily standardization processing of basic data in the user basic information domain [scenario description]"), thus completing the extraction of domain-related rules. This extraction process differs from the traditional method of only extracting "node flow relationships," focusing on incorporating timeliness constraints and data quality constraints in the financial scenario to ensure that the rules can directly support compliant data processing within the domain.

[0105] II. Implementation of Inter-Domain Association Rule Extraction

[0106] First, an inter-domain subgraph is extracted from the risk assessment metadata lineage graph. This subgraph contains core information such as "cross-domain field grouping table, inter-domain transmission interface information table, inter-domain conversion algorithm unit, and inter-domain verification rule unit".

[0107] The first step is to extract the data interaction triggering rules between domains based on the cross-domain field grouping table—analyze the cross-domain flow triggering conditions of the same cross-domain field group (such as the "G001-User Identifier Association" field group) (e.g., the cross-domain triggering condition for the "User Identifier" field between the user basic information domain and the behavioral feature domain is "when the missing rate of the 'Account ID' field in the behavioral feature domain exceeds 5%, an automatic request for the 'User Number' field is initiated to the user basic information domain"; the cross-domain triggering condition for the "Credit Rating" field between the behavioral feature domain and the external associated domain is "when the update frequency of the 'Third-Party Credit Rating' in the external associated domain exceeds 24 hours / time, it is actively pushed to the behavioral feature domain"), and generate a list of inter-domain triggering rules;

[0108] The second step involves extracting inter-domain interface adaptation rules from the inter-domain transmission interface information table—clarifying the binding relationship between cross-domain field groups and transmission interfaces, as well as interface call constraints (e.g., the "G001-User Identifier Association" field group must be transmitted through the "Internal Cross-Domain API Interface UBG-001", and the call must meet the requirements of "request interval not less than 1 second" and "the number of fields in a single request not exceeding 100"; the "G002-Credit Rating Association" field group must be transmitted through the "Third-Party HTTPS Interface BIG-002", and must carry the inter-domain session key from step 112 for identity verification), generating a list of inter-domain interface adaptation rules.

[0109] The third step involves extracting inter-domain data consistency rules based on the inter-domain conversion algorithm unit and the inter-domain verification rule unit—integrating format conversion logic and verification requirements (e.g., the format conversion rule for "User ID" in the user basic information domain to "Account ID" in the behavioral feature domain is "BH_" prefix + 10 digits, and after conversion, it needs to pass two layers of verification: "prefix validity verification" and "digit verification"; the mapping rule for "Third-party credit rating" in the external association domain to "Internal credit score" in the behavioral feature domain is "AAA → 850-950 points, AA → 750-849 points", and after mapping, it needs to verify whether "the matching degree between the internal value and the third-party rating exceeds 90%"). This generates a list of inter-domain data consistency rules.

[0110] Finally, the inter-domain triggering rule list, interface adaptation rule list, and data consistency rule list are integrated according to the structure of "cross-domain field group identifier - rule type - rule content - security configuration requirements," and encapsulated into an inter-domain association rule unit, thus completing the extraction of inter-domain association rules. This extraction process focuses on the security and data consistency of cross-domain transmission, solving the problem that traditional extraction ignores inter-domain security configuration and verification logic, and adapting to the highly sensitive characteristics of cross-domain financial data.

[0111] III. Implementation of Application Layer Association Rule Extraction

[0112] First, an application layer subgraph is extracted from the risk assessment metadata lineage graph. This subgraph contains core information such as "model application node topology, data input / output mapping table, model parameter association table, and assessment result impact weight table".

[0113] The first step is to extract model data access rules based on the data input-output mapping table—clarifying the dimension matching requirements for risk assessment labeled metadata to access the model (e.g., fields labeled "Credit Status - Historical Overdue Counts" can only be accessed through the "Credit Dimension Data Access Node" and cannot be accessed through the "Performance Dimension Data Access Node"; fields labeled "Cross-Dimensional Related Fields" for "Guarantee Records" must be accessed through access nodes of both dimensions simultaneously, and the access order is "Credit Dimension First, Performance Dimension Lagging by 100ms"), and generating a list of model data access rules;

[0114] The second step involves extracting model parameter association rules from the model parameter association table—analyzing the binding relationship between fields and model parameters, as well as parameter adjustment constraints (e.g., the "historical overdue number" field is only associated with the "overdue number coefficient of the logistic regression sub-model," and the adjustment range of this coefficient needs to be controlled between -0.3 and -0.2, and the threshold parameter of the "feature normalization node" needs to be updated synchronously after adjustment; the "average monthly income stability" field is only associated with the "income stability split threshold of the gradient boosting tree sub-model," and the threshold adjustment needs to refer to the fluctuation range of income data in the past 3 months, and the threshold can be reduced by 5% when the fluctuation range exceeds 15%), generating a list of model parameter association rules;

[0115] The third step is to extract the impact rules of the assessment results based on the impact weight table—the logic of the impact of quantitative fields on the risk assessment results (e.g., for every 0.1 increase in the normalized value of the "historical overdue number" field, the risk score decreases by an average of 5-8 points, and this impact weight is higher in the low-credit user group with "credit score < 650 points"; for every 10% decrease in the percentage value of the "average monthly income stability" field, the probability of the risk level decreasing from "good" to "average" increases by 12%-15%), and generate a list of impact rules of the results.

[0116] Finally, the model data access rule list, parameter association rule list, and result impact rule list are integrated according to the structure of "model node identifier - rule type - rule content - assessment scenario adaptation description" and encapsulated into application-layer association rule units, completing the extraction of application-layer association rules. This extraction process directly binds data association with model evaluation results, unlike the traditional method of only extracting "data input-output relationships," ensuring that the rules can directly support parameter optimization and result traceability of the risk assessment model.

[0117] Finally, the extracted intra-domain association rule units, inter-domain association rule units, and application-layer association rule units are integrated to form three types of association rule sets. This set serves as the core input for "building a full-domain association rule base" in step 42. The scenario-based constraints and security configurations it contains provide a clear scenario basis for subsequent rule priority ranking, ensuring that the full-domain association rule base meets the business and compliance needs of financial users' risk assessment.

[0118] Optionally, step 4 specifically includes: Step 41: Constructing a full-domain association rule library by adopting the following approach for intra-domain association rules, inter-domain association rules, and application-layer association rules: intra-domain rules have higher priority than inter-domain rules, direct association rules have higher priority than indirect association rules, and application-layer association rules have higher priority than intra-domain association rules.

[0119] Preferably, the specific implementation process of step 41 is as follows: First, the processing objects are determined to be the intra-domain association rules, inter-domain association rules, and application layer association rules extracted from the risk assessment metadata lineage graph (all of which have been encapsulated into standardized rule units containing rule ID, rule type, core content, association strength value, and applicable scenario description). In the financial user risk assessment scenario, the business logic of "prioritizing result accuracy, intra-domain stability, and direct association reliability" is adopted. A five-level processing logic of "rule preprocessing - priority evaluation system construction - hierarchical sorting - conflict arbitration - rule base encapsulation" is adopted to construct a full-domain association rule base that meets the scenario requirements.

[0120] In the rule preprocessing stage: The three types of standardized rule units are formatted and supplemented with information to ensure consistency in subsequent priority evaluation. The first step is to standardize the rule identifier format, assigning each rule unit a unique ID consisting of "rule type prefix - rule sequence number" (e.g., application-layer related rules are prefixed with "APP-", intra-domain related rules with "DOM-", and inter-domain related rules with "CRO-"), facilitating rapid identification of the rule type. The second step is to supplement the rule impact scope label, marking the data scope (e.g., "user identification fields", "credit scoring fields", "performance capability fields") and business impact level (e.g., "core evaluation fields", "auxiliary verification fields") based on the rule content and applicable scenario description. For example, "A The "PP-001" rule (model parameter association rule) is marked as "Core Assessment Field - Risk Score Impact," and the "DOM-005" rule (domain-specific format constraint rule) is marked as "Auxiliary Validation Field - Data Consistency Guarantee." The third step involves quantifying the rule association strength value. Combining the strength values ​​of the node association matrix in the risk assessment metadata lineage graph, the rule association strength value is standardized to a score of 0-10 (the original association strength value of 0-1 is magnified by a factor of 10). For example, an original association strength of 0.8 corresponds to a standardized score of 8, and an original association strength of 0.3 corresponds to a standardized score of 3. This score is used for subsequent priority fine-tuning. After preprocessing, a global rule candidate set with "unified identifiers, complete labels, and quantified strength" is generated, providing standardized input for priority assessment.

[0121] In the priority evaluation system construction phase: A three-dimensional evaluation system of "basic priority + scenario-based weight + correlation strength correction" is constructed to meet the needs of financial scenarios, avoiding the limitations of traditional single-dimensional ranking. The first step is to set basic priority ranking standards based on the impact of three types of rules on risk assessment business: Application-layer correlation rules directly relate to the parameter configuration and result output of the risk assessment model, having a high impact on the accuracy of the assessment results, and are set to the highest basic priority (Level A); Intra-domain correlation rules ensure the stability and consistency of data processing within a single data domain, serving as the foundation for cross-domain correlation and model application, and are set to a medium basic priority (Level B); Inter-domain correlation rules involve cross-domain data interaction and are more affected by external factors such as interface stability and the reliability of conversion algorithms, and are set to the lowest basic priority (Level C). Therefore, the basic priority ranking is "Application-layer correlation rules (A) > Intra-domain correlation rules (B) > Inter-domain correlation rules (C)". The second step is to configure scenario-based weights, assigning weight coefficients to rules at different business impact levels: rules marked as "core evaluation fields" have a weight coefficient of 1.2 (weight increase), and rules marked as "auxiliary validation fields" have a weight coefficient of 0.8 (weight decrease). This coefficient is used to adjust the actual priority score of the rules. The third step is to introduce a correlation strength correction item, converting the standardized correlation strength score (0-10) of rules into a correction score at a rate of 10% (e.g., a score of 8 corresponds to a correction score of 0.8, and a score of 3 corresponds to a correction score of 0.3), used to fine-tune the ranking of rules at the same level. The final three-dimensional evaluation formula is: Actual priority score of a rule = Basic priority score (A=10, B=7, C=4) × Scenario-based weight coefficient + Correlation strength correction score. This formula ensures that the priority ranking meets both the core needs of the scenario and the actual correlation effect of the rules.

[0122] In the hierarchical sorting stage: Based on the three-dimensional evaluation system, the candidate set of rules across the entire domain is hierarchically sorted to ensure that the rule order is consistent with the scenario requirements. The first step is to stratify by basic priority level, first selecting rules with a basic priority of A (application layer), then selecting rules at levels B (intra-domain) and C (inter-domain), forming a three-level rule layer; the second step is to sort again within the same basic priority level according to the principle of "directly related rules take precedence over indirectly related rules"—determining the association type through the core content of the rules: directly related rules describe the direct interaction relationship between two nodes / fields (e.g., rule "APP-003": "historical overdue number field directly related to logistic regression sub-model overdue coefficient"), while indirectly related rules describe the association relationship passed through intermediate nodes / fields (e.g., rule "CRO-012": "user basic information field 'body'..."). The first step involves indirectly associating the ID number with the external domain 'ID Number' through a 'third-party identity verification node'. Within the same level, the actual priority score of directly associated rules is increased by 1.0 (additional weight) to ensure their higher ranking. The second step involves sorting rules by their actual priority scores from highest to lowest within the same association type. For example, in application-layer direct association rules, "APP-001" (score 10×1.2+0.9=12.9) ranks higher than "APP-005" (score 10×1.0+0.7=10.7). In domain-level direct association rules, "DOM-002" (score 7×1.2+0.8=9.2) ranks higher than "DOM-008" (score 7×0.8+0.6=6.2). This hierarchical sorting generates an ordered rule list, clearly defining the order of rule invocation and execution.

[0123] During the conflict arbitration phase: For potential rule conflicts in the ordered rule list (i.e., different rules have inconsistent constraints on the same data / node), an arbitration mechanism of "priority-driven + scenario compliance verification" is adopted to ensure the consistency of the rule base. The first step is to identify conflicting rule pairs and filter rules that apply to the same data range using rule impact scope tags (e.g., the "DOM-003" intra-domain formatting rule and the "CRO-007" inter-domain conversion rule both applying to the "User ID" field). The second step is to arbitrate according to priority level. The constraints of higher priority rules (e.g., Class A) override those of lower priority rules (e.g., Class B and Class C). For example, if the application layer rule "APP-006" requires "credit score field to retain 1 decimal place," while the intra-domain rule "DOM-010" requires "retain 2 decimal places," then the "APP-006" rule prevails. The third step involves conflict arbitration within the same priority level. If rules of the same level conflict (e.g., two rules within the B-class domain), the rule with the higher scenario-based weight coefficient is prioritized (e.g., the "core assessment field" rule overrides the "auxiliary verification field" rule). If the weight coefficients are the same, the rule with the "higher verification pass rate" is selected by referring to the compliance verification markers in the risk assessment metadata lineage graph (e.g., a rule with a 98% verification pass rate is better than a rule with a 92% pass rate). The fourth step involves recording the conflict arbitration results to form a "Rule Conflict Arbitration Log," noting the conflicting rule ID, conflict content, arbitration basis, and result, facilitating subsequent rule maintenance and auditing. After arbitration, a list of conflict-free ordered rules is generated to ensure logical consistency between rules.

[0124] In the rule base encapsulation phase: The list of conflict-free, ordered rules is categorized and stored according to a three-dimensional structure of "rule type - data scope - business impact level," constructing a globally relevant rule base that can be quickly retrieved and accessed. The steps are as follows: First, divide the rule base into first-level directories (application layer rule directory, intra-domain rule directory, inter-domain rule directory); second, under each first-level directory, divide it into second-level subdirectories based on data scope (e.g., "user identifier", "credit scoring", "performance capability"); third, under each second-level subdirectory, divide it into third-level subdirectories based on business impact level ("core assessment fields", "auxiliary verification fields"); fourth, configure the rule base with a search engine that supports precise searches by rule ID, data scope, business impact level, and keywords (e.g., "format constraints", "parameter association"), while also supporting rule access permission configuration (e.g., "core assessment field" rules are only accessible to risk assessment model administrators). Finally, a full-domain association rule library is generated, which includes a directory structure, search function, and access control. This library not only clarifies the priority order of rules, but also adapts to the compliance and permission requirements of financial scenarios. Unlike traditional unstructured rule sets, it can directly support the visualization construction of the full-domain data source asset map in step 43 and subsequent business calls.

[0125] Optionally, step 4 specifically includes: Step 42: Based on the global association rule base, a three-dimensional force-oriented layout is used for visualization rendering to generate a global data source asset map containing "global data domain overview layer - intra-domain node distribution layer - cross-domain association detail layer";

[0126] Preferably, the specific implementation process of step 42 is as follows: First, the processing object is determined to be the aforementioned generated full-domain association rule base and risk assessment metadata lineage map (including node attributes, association relationships, and hierarchical indexes). In response to the requirements of "hierarchical clarity, intuitive association, and risk identifiability" for data visualization in the risk assessment scenario of financial users, a four-order implementation framework of "three-dimensional spatial mapping - force-oriented layout optimization - hierarchical rendering engine - interactive rule binding" is adopted to generate a full-domain data source asset map that supports multi-level drill-down.

[0127] In the three-dimensional spatial mapping stage: based on the business characteristics of the financial data domain, a three-dimensional coordinate system of "data domain - business dimension - circulation stage" is constructed to transform abstract rules and graph information into spatially locatable visual elements. The first step is to define the meaning of the three-dimensional coordinate axes: The X-axis represents the data domain dimension, which maps from left to right to the user basic information domain, behavioral feature domain, and external association domain. Each data domain occupies a continuous interval (e.g., the user basic information domain corresponds to X=0-300, the behavioral feature domain corresponds to X=300-600, and the external association domain corresponds to X=600-900, in pixels); The Y-axis represents the business evaluation dimension, which maps from bottom to top to the user credit status evaluation dimension and the user repayment ability evaluation dimension. Each dimension is divided into intervals by sub-items (e.g., the "historical overdue" sub-item of the credit status dimension corresponds to Y=100-200, and the "repayment record" sub-item corresponds to Y=200-300); The Z-axis represents the data flow stage, which maps from back to front to the data collection stage, processing and transformation stage, and model application stage. The stage depth is positively correlated with the data processing complexity (e.g., the collection stage corresponds to Z=50, and the model application stage corresponds to Z=200). The second step is to map the spatial coordinates of nodes: Extract the core nodes (including data field nodes, processing nodes, and model nodes) from the risk assessment metadata lineage graph. Calculate the three-dimensional coordinates of the nodes based on their "data domain affiliation label," "business dimension label," and "transition stage attribute" (e.g., the coordinates of the "User Basic Information Domain - Credit Status - Historical Overdue Count" field node are X=150, Y=150, Z=100). Assign spatial size parameters to the nodes, determining the size based on the node's priority score in the global association rule base (the actual priority score calculated in step 42). The higher the score, the larger the node radius (e.g., a node with a score of 12 has a radius of 20 pixels, and a node with a score of 5 has a radius of 8 pixels). The third step is to map the spatial attributes of association lines: Extract the rule association relationships from the global association rule base. Each association line corresponds to a spatial connection between two nodes. The line width is positively correlated with the rule association strength value (strength value 10 corresponds to a line width of 5 pixels, strength value 3 corresponds to a line width of 1 pixel). The line color is distinguished according to the rule type (application layer association rules are dark blue, intra-domain association rules are green, and inter-domain association rules are orange). After mapping in three-dimensional space, a "coordinated node set" and an "attributed association line set" are generated, providing a spatial data foundation for subsequent layout optimization.

[0128] In the force-oriented layout optimization phase: Addressing the characteristics of dense financial data nodes and complex cross-domain relationships, the traditional force-oriented algorithm is improved by using "scenario-based force parameter configuration" to reduce node overlap and intersection of correlation lines, thereby enhancing visualization clarity. The first step is to define the basic mechanical model: each node is assigned a repulsive force (to avoid overlap) and an attractive force (to maintain correlation). The repulsive force is positively correlated with the node radius and negatively correlated with the square of the node spacing; the attractive force is positively correlated with the correlation line strength and the node spacing. The second step is to configure scenario-based force parameters: different repulsive force coefficients are applied to different types of nodes—nodes marked as "core evaluation fields" (such as "historical overdue number" and "average monthly income") have their repulsive force coefficient increased by 20% (to avoid being obscured by other nodes), while the repulsive force coefficient of "auxiliary verification field" nodes is reduced by 10%; an enhanced attractive force coefficient (30% higher than intra-domain correlation lines) is used for cross-domain correlation lines to ensure that cross-domain relationships are more prominent in three-dimensional space. The third step is to set boundary constraints: Add data domain boundary forces in the 3D coordinate system (e.g., set a virtual boundary at X=300 in the user basic information domain, and apply a reverse thrust to nodes that exceed the boundary) to prevent nodes from overflowing their data domain range; set hierarchical constraints on the Z-axis (transition stage), ensuring that the Z-coordinate deviation of nodes in the same stage does not exceed 20 pixels, and ensuring clear stage layering. The fourth step is to iteratively optimize the layout: Adjust the node positions through multiple rounds of mechanical simulation. After each iteration, calculate the "number of intersections of related lines" and the "node overlap rate". Stop the iteration when the number of intersections is lower than a threshold (e.g., 15% of the total number of related lines) and the overlap rate is lower than 5%, generating optimized 3D layout data (including final node coordinates and related line paths). This optimization process differs from the uniform parameter settings of traditional force-oriented algorithms. It adapts scenario-based parameters to the business priorities of financial data, making core nodes and key connections more prominent.

[0129] In the layered rendering engine stage: Based on the optimized 3D layout data, a differentiated rendering strategy is adopted according to the hierarchical structure of "overall data domain overview layer - intra-domain node distribution layer - cross-domain association detail layer" to achieve a visualization presentation from macro to micro. The first step is to render the overall data domain overview layer: Based on a simplified 3D space, each data domain is rendered as a semi-transparent cube (user basic information domain is light blue, behavioral feature domain is light green, and external association domain is light orange). The number of aggregated nodes and core rules within the domain is displayed inside the cube (e.g., "user basic information domain: 120 nodes, 35 core rules"). Different cubes are connected by bold cross-domain association lines, and the transparency of the lines increases as the association strength decreases (the transparency of the line with a strength value of 10 is 100%, and the transparency of the line with a strength value of 3 is 60%). The overview layer hides the details of individual nodes and only retains the overall distribution of inter-domain associations, helping users quickly grasp the coverage of the overall data. The second step is to render the node distribution layer within the domain: When a user clicks on a data domain cube, the system triggers drill-down rendering to display the nodes and association rules within that domain—nodes are distributed according to business dimensions (Y-axis) and flow stages (Z-axis), and different shapes are used to distinguish node types (data field nodes are spheres, processing nodes are cubes, and model nodes are cones); association lines within the domain are rendered according to rule priority (high-priority rule lines are given a glowing effect); at the same time, statistical information on the core rules within the domain is displayed (such as "within the behavioral feature domain, 85% of the association rules are direct associations"). The third step is to render the detailed layer of cross-domain associations: When a user clicks on a cross-domain association line in the overview layer, the system focuses on rendering the nodes involved in the association, the transmission path, and the details of the association rules—highlighting the nodes at both ends of the association line (magnified 1.5 times), and marking the intermediate transmission interface nodes with dashed lines; dynamically displaying a summary of the rule content next to the association line (e.g., "CRO-005 rule: User ID field is transmitted across domains via UBG-001 interface, synchronized once daily"); and simultaneously displaying the compliance verification results of the association in the sidebar (e.g., "Transmission success rate 99.2% in the past 30 days, format verification pass rate 100%"). After layered rendering, a visual view supporting hierarchical drill-down is generated, satisfying both the need for a macro overview and the ability to delve into detailed queries.

[0130] In the interaction rule binding phase: Configure interactive functions for the 3D visualization view that conform to the operational habits of financial scenarios, realizing convenient view operation and information query. The first step is to bind basic navigation interactions: support mouse drag to rotate the 3D view (rotate around the X, Y, and Z axes), scroll wheel zoom (zoom range limited to 50%-200% of the original size), and left-click to select nodes / connection lines (selected elements display a highlighted border); set the default viewpoint to a 45° top-down view to ensure that information in all three dimensions is visible simultaneously. The second step is to bind hierarchical drill-down interactions: in the overview layer, clicking the data domain cube → enters the domain node distribution layer; in the domain layer, clicking the "back" button → returns to the overview layer; in the overview layer, clicking a cross-domain connection line → pops up the cross-domain connection detail layer; in the detail layer, clicking "close" → returns to the overview layer; add smooth transition animations (such as fade-in / fade-out, position translation) during drill-down to improve the user experience. The third step is to bind the information query interaction: when a node is selected, a node details card is displayed (including node identifier, data domain affiliation, business tag, and number of associated rules); when an association line is selected, a rule details card is displayed (including rule ID, priority score, core content, and applicable scenarios); the right-click menu supports triggering the "View Full Link" function (jumping to the cross-domain traceability engine in step 44). The fourth step is to bind the risk identification interaction: a red warning border is added to nodes with the sensitivity tag "high", and a yellow flashing effect is added to association lines marked "pending verification" to help users quickly identify high-risk data assets. After the interactive rules are bound, a complete full-domain data source asset map is generated. This map not only realizes the three-dimensional visualization of data assets, but also adapts to the business needs of financial users' risk assessment through layered design and scenario-based interaction. Unlike traditional two-dimensional static maps, it can intuitively display the full-domain picture of data domain distribution, node association, and rule constraints.

[0131] Optionally, step 43: Configure a cross-domain traceability engine for the global data source asset map, which supports the display of its full-link flow trajectory in the user basic information domain, behavioral feature domain, and external association domain by inputting any data field.

[0132] Preferably, in the specific implementation of step 43, the core module architecture of the cross-domain tracing engine is first constructed, and the processing objects are the asset map of the full-domain data source, the lineage map of risk assessment metadata, and the full-domain association rule base. This architecture includes three financial scenario-specific modules: First, a field full-domain index library, which extracts the core identification information of all fields, constructs a multi-dimensional index table with "semantic association index" (associating and storing synonymous fields such as "user number" and "account ID"), and binds the "core association node ID" of the fields, supporting real-time synchronous updates; Second, a full-link data caching module, which caches link data in shards according to "field ID - flow stage" (collection, intra-domain processing, cross-domain transmission, model application), uses memory caching (response ≤ 1 second) for the top 30% of core fields in the rule base (such as "historical overdue number of times"), and uses disk caching for non-core fields and preloads fields retrieved in the past 7 days; Third, a visualization linkage interface module, which designs a two-way interface of "view control + data feedback", supports the engine to send highlight / drill-down commands to the map, and can also receive user interaction data from the map to ensure that tracing and visualization are synchronized. This module architecture differs from traditional single-function engines, adapting to the characteristics of financial data through semantic association and hotspot caching.

[0133] Preferably, in the specific technical implementation of step 43, a multi-dimensional field retrieval mechanism is constructed based on the core module to solve the problem of retrieving fields with "synonymous but different names" in financial scenarios. First, the system receives the user's input retrieval conditions (field name, ID, or any data domain) and triggers an exact match retrieval: it queries the "exact identifier column" in the field's full-domain index library. If a match is found, it returns the core association node information of the field; if a fuzzy match is found, it generates a candidate list containing "data domain-hierarchical labels". If no exact match is found, it automatically initiates a semantic association retrieval: it combines the semantic dictionary of financial risk assessment scenarios to calculate the semantic similarity between the input text and the field definition (the threshold is generally set to 0.7), and associates the cross-domain association index code to filter out semantically related fields (such as associating "account ID" with "user number"), and marks the association basis. Finally, it supports scenario-based filtering retrieval, where users can select conditions such as "recent 30-day link" and "core assessment field", and combine the "business impact level" of the rule library with the timestamp of the lineage graph to perform a secondary filtering of the results, ensuring that the retrieval meets the risk assessment needs.

[0134] Preferably, in one scenario, when implementing step 43, the entire link flow trajectory of the field is reconstructed based on the search results. First, the link data of the target field is extracted from the full-link data caching module, and the node sequence is organized according to "collection stage → intra-domain processing stage → cross-domain transmission stage → cross-domain processing stage → model application stage" (e.g., "third-party credit reporting interface → format conversion node → cross-domain interface → data verification node → model calculation node"), and the processing time and data form changes of each stage are marked. Then, the core information of the financial key nodes is marked: the collection stage is marked with the filtering rule of "association strength ≥ 0.7" and the source system; the cross-domain stage is marked with HTTPS protocol, AES-256 encryption and verification pass rate (e.g., 99.8% in the last 30 days); the model stage is marked with the associated parameters (e.g., overdue coefficient -0.25) and the evaluation impact weight (e.g., 18%). If there are missing node logs, "missing nodes" are marked and a speculative link is generated based on the full-domain association rules (e.g., speculative format conversion logic according to rule CRO-012) to ensure the integrity of the link and meet the compliance traceability requirements.

[0135] Preferably, the specific implementation process of step 43 is as follows, finally completing the visual linkage display and traceability report generation. Through the visual linkage interface, the restored link is linked with the asset map of the full-domain data source: the full-domain overview layer highlights cross-domain links with bold red connection lines, and the data domain cube displays the number of transfers; after the user clicks, drill down to the intra-domain / cross-domain layer, highlighting the corresponding node and connection line, and displaying the rule summary when the mouse hovers over it (such as "Intra-domain rule DOM-023: Convert first and then transmit"); at the same time, a details panel is generated to display node operation logs, rule priorities, and compliance verification results (such as "2024-05-18 Format error has been automatically corrected"). In addition, it supports the generation of structured traceability reports, which organize content according to "search conditions - link overview - stage details - compliance summary", and mark the compliance risk level (such as "high compliance: pass rate 99.2%), and can be exported to PDF (audit), Excel (analysis), and HTML (interactive) formats, providing a choice of simplified / full version, which is different from traditional tools that only locate nodes, realizing full-link traceability and verifiability in financial scenarios.

[0136] Figure 2 This is a schematic diagram of the structure of an automatic generation device for a global data source asset map according to an embodiment of this application. Figure 2 As shown, it includes:

[0137] Extraction unit: used to acquire multi-source heterogeneous data in financial user risk assessment scenarios and extract metadata from it to generate original metadata for risk assessment. The multi-source heterogeneous data is matched with the user basic information domain, behavioral feature domain, and external association domain.

[0138] Semantic annotation unit: used to perform bidirectional semantic mapping annotation on the original risk assessment metadata based on the user credit status assessment dimension and the user performance capability assessment dimension, so as to generate risk assessment labeled metadata with data domain attribution labels;

[0139] Lineage building unit: used to build traceable data lineage links based on risk assessment labeled metadata, so as to generate a risk assessment metadata lineage map containing inter-domain relationships;

[0140] Association Generation Unit: Used to construct cross-domain data association rules based on the risk assessment metadata lineage map, in order to generate a full-domain data source asset map.

[0141] The evaluative descriptions such as "precise" and "accurate" mentioned in this application should be objectively understood in conjunction with the technical background and existing technology level, and are not intended to describe an absolute ideal state of technical effect. For those skilled in the art, the core function of such descriptions is to objectively reflect the relative improvement in technical effect achieved by this application through specific technical designs such as "bidirectional semantic mapping annotation," "hierarchical lineage link construction," and "priority ranking of full-domain association rules"—that is, compared with existing technologies, the solution of this application presents superior performance in terms of the rationality of data domain associations, the clarity of full-link traceability, and the adaptability of risk assessment—rather than an absolute promise of technical effect. This method of description meets the rigor requirements of technical solution description, enabling those skilled in the art to clearly identify the differences in technical effect between this application and existing technologies, and accurately grasp the improvement value of the solution.

Claims

1. A method for automatically generating asset maps from a global data source, characterized in that, include: Step 1: Obtain multi-source heterogeneous data in the financial user risk assessment scenario and extract its metadata to generate original metadata for risk assessment. The multi-source heterogeneous data is matched with the user basic information domain, behavioral feature domain, and external association domain. Step 2: Perform bidirectional semantic mapping annotation on the original risk assessment metadata based on the user credit status assessment dimension and the user performance capability assessment dimension to generate risk assessment labeled metadata with data domain attribution tags; Step 3: Construct a traceable data lineage based on risk assessment annotation metadata to generate a risk assessment metadata lineage map containing inter-domain relationships; Step 4: Based on the risk assessment metadata lineage map, construct cross-domain data association rules to generate a full-domain data source asset map.

2. The method according to claim 1, characterized in that, Step 1 specifically involves: obtaining multi-source heterogeneous data from independent storage nodes of the user basic information domain, behavioral feature domain, and external association domain to generate basic metadata fields; and generating risk assessment raw metadata containing full-domain data domain coverage information in the user basic information domain, behavioral feature domain, and external association domain based on the basic metadata fields.

3. The method according to claim 2, characterized in that, Step 1 specifically includes: Step 11: Based on a preset distributed cross-domain data acquisition protocol, multi-source heterogeneous data is obtained from independent storage nodes in the user basic information domain, behavioral feature domain, and external association domain, respectively. The multi-source heterogeneous data includes structured data, semi-structured data, and unstructured data.

4. The method according to claim 3, characterized in that, Step 11 specifically includes the following steps: Step 111: Construct a data domain identity authentication center and assign cross-domain access tokens to each independent storage node of the user basic information domain, behavioral feature domain, and external association domain; Step 112: Establish an encrypted data transmission channel based on the cross-domain access token. The encrypted data transmission channel uses an inter-domain key negotiation mechanism to dynamically generate session keys. Step 113: Send a timestamped collection instruction to the user basic information domain, behavioral feature domain, and external association domain through an encrypted data transmission channel. The collection instruction includes data domain-specific filtering rules for filtering by identity in the user basic information domain, by time window in the behavioral feature domain, and by association strength in the external association domain. Step 114: Receive encrypted data packets returned from the user basic information domain, behavioral feature domain, and external association domain, and verify the data packet signature of the encrypted data packet through the data domain identity authentication center to obtain multi-source heterogeneous data after decryption.

5. The method according to claim 2, characterized in that, Step 1 specifically includes: Step 12: Perform field-level standardized parsing on the acquired heterogeneous data to extract field definitions, data types, format specifications and source system identifiers, and generate basic metadata fields.

6. The method according to claim 2, characterized in that, Step 1 specifically includes: Step 13: Adding a data domain affiliation identifier and a cross-domain association index code to the basic metadata field. The cross-domain association index code is used to identify semantically related metadata fields in different data domains.

7. The method according to claim 2, characterized in that, Step 1 specifically includes: Step 14: Integrate the basic metadata fields with data domain identifiers to generate risk assessment raw metadata containing information covering all data domains in the user basic information domain, behavioral feature domain, and external association domain.

8. The method according to claim 1, characterized in that, Step 2 specifically involves: determining credit mapping pairs and performance mapping pairs based on the field semantic vectors of the original risk assessment metadata, as well as the sub-item vectors of user credit status assessment dimensions and user performance capability assessment dimensions; and generating risk assessment annotation metadata that simultaneously includes user credit status assessment dimension labels, user performance capability assessment dimension labels, and data domain affiliation labels based on the credit mapping pairs and performance mapping pairs.

9. The method according to claim 8, characterized in that, Step 2 specifically includes: Step 21: Constructing a semantic mapping model with a bidirectional attention mechanism. The input layer of the semantic mapping model receives the field semantic vectors of the original metadata of risk assessment, as well as the sub-item vectors of user credit status assessment dimension and user performance capability assessment dimension.

10. The method according to claim 8, characterized in that, Step 2 specifically includes: Step 22: Through the dual-path parallel computing module of the hidden layer of the semantic mapping model, calculate the first cosine similarity between the field semantic vector and the user credit status assessment dimension sub-item vector, and the second cosine similarity between the field semantic vector and the performance capability assessment dimension sub-item vector.

Images