A sensitive data desensitization method for a banking service scenario

Abstract

The application discloses a sensitive data desensitization method for a bank service scene, and belongs to the technical field of data desensitization, and comprises the following steps: obtaining a query result set, and traversing fields in the query result set; identifying whether the fields belong to sensitive fields based on semantic features of the fields, wherein the sensitive fields at least include one or more types of a name field, a mobile phone number field, an ID number field, a bank card number field and an account number field; selecting corresponding desensitization rules from a preconfigured desensitization rule set according to types of the identified sensitive fields; performing field-level desensitization processing on the query result set, replacing sensitive data field by field according to the selected desensitization rules, and generating a desensitized result set. By identifying dynamically changing query result fields, desensitization omission caused by non-uniform field naming is avoided, and by using a differentiated desensitization strategy, sensitive information is protected while data service availability is retained.

Description

Technical Field

[0001] This invention belongs to the field of data anonymization technology, specifically relating to a method for anonymizing sensitive data in banking business scenarios. Background Technology

[0002] With the accelerated advancement of digital transformation in the financial sector, data security issues in the banking business are becoming increasingly prominent. Bank intelligent analytics results typically contain sensitive information such as customer names, mobile phone numbers, ID card numbers, bank card numbers, and account numbers. Ensuring data availability while preventing the leakage of sensitive information has become a core technical challenge in the field of bank data governance.

[0003] Banks are increasingly adopting intelligent query technologies such as NL2SQL (Natural Language to Structured Query Language) to lower the barrier to data querying and improve business analysis efficiency. However, existing NL2SQL solutions generally suffer from inherent deficiencies in access control and security auditing capabilities from their initial design. In intelligent query scenarios, query results are dynamically generated, and the field composition changes depending on the user's question, which presents new technical challenges for the anonymization and protection of sensitive data.

[0004] Existing data masking solutions mostly employ a static approach based on a fixed list of fields. This involves pre-configuring a list of fields to be masked, and only fields in the list are masked after the query is returned. However, in intelligent query scenarios, the fields in the query results are dynamically generated, and the field names change depending on the user's question. Traditional static data masking rules cannot effectively cover dynamically changing result set fields, easily leading to omissions in data masking.

[0005] Furthermore, banks have massive amounts of internal data, and similar sensitive fields may have multiple naming conventions across different business systems. Current technology relies on exact field name matching for sensitive field identification, which struggles to handle situations with significant differences in field naming, resulting in sensitive fields not being accurately identified during cross-table queries.

[0006] The aforementioned technical issues are interconnected and collectively constrain the effective protection and compliance management of sensitive data in banking intelligent analytics scenarios. How to automatically identify and differentiate sensitive fields in dynamic query results is a pressing technical problem that needs to be solved in the field of banking data governance. Summary of the Invention

[0007] This invention provides a sensitive data de-identification method for banking business scenarios. By obtaining a query result set and traversing its fields, it automatically identifies whether a field is a sensitive field based on the semantic features of the field. Then, it selects the corresponding de-identification rule from a pre-configured set of differentiated de-identification rules according to the identified sensitivity type. This solves the data leakage risks caused by existing technologies, such as the difficulty of de-identification rules covering dynamically changing result set fields, inconsistent field naming leading to omissions in sensitive field identification, and the inability of single de-identification rules to take into account all data.

[0008] The technical solution adopted in this invention is as follows: A method for de-identifying sensitive data in banking business scenarios, comprising: Retrieve the query result set and iterate through the fields in the query result set; Based on the semantic features of the field, it is determined whether the field is a sensitive field. The sensitive fields include at least one or more types of fields such as name, mobile phone number, ID number, bank card number, and account number. Based on the type of the identified sensitive fields, select the corresponding desensitization rule from the pre-configured desensitization rule set; The query result set is subjected to field-level desensitization processing. Sensitive data is replaced field by field according to the selected desensitization rules to generate a desensitized result set.

[0009] Among them, identifying whether a field is a sensitive field based on its semantic features includes: The semantic features include field names and field values; Perform keyword matching based on field names to determine whether the field names contain preset sensitive keywords. The sensitive keywords include at least one or more of the following: name-related keywords, mobile phone number-related keywords, ID number-related keywords, bank card number-related keywords, and account number-related keywords; and / or, If the field value meets the preset conditions, then perform regular expression pattern matching based on the field value to identify sensitive fields.

[0010] Keyword matching is performed based on field names to determine whether the field names contain preset sensitive keywords. Specifically: Based on the frequency of banking transactions, determine the matching order for different types of sensitive keywords. Based on field names, matching is performed on different types of sensitive keywords in a predetermined matching order.

[0011] Based on the frequency of banking transactions, determine the matching order for different types of sensitive keywords, specifically as follows: When the frequency of banking transactions is higher than or equal to the preset threshold, matching is performed in the following order: name-related keywords, mobile phone number-related keywords, ID number-related keywords, bank card number-related keywords, and account number-related keywords. When the frequency of banking transactions is lower than a preset threshold Matching should be performed in the following order: mobile phone number-related keywords, bank card number-related keywords, account number-related keywords, name-related keywords, and ID number-related keywords. Matching is performed in the following order: keywords related to mobile phone number, keywords related to name, keywords related to ID number, keywords related to bank card number, and keywords related to account number.

[0012] The field value meets the preset conditions, specifically: The data type of the field value is string. Furthermore, the number of fields with non-empty values ​​reaches the preset minimum sample size.

[0013] Perform field-level data masking on the query result set, including: Use a nested loop to iterate through each row and column of the query result set; For the current traversal position, determine whether the field corresponding to that position is a sensitive field; If it is a sensitive field, the desensitization rule function corresponding to the sensitive field type will be called to replace the original value with the desensitized value; If it is not a sensitive field, keep the original value unchanged; After the traversal is complete, output the anonymized result set.

[0014] Based on the type of the identified sensitive fields, select the corresponding desensitization rule from the pre-configured set of desensitization rules, including: For the name field, the first character is retained and the remaining characters are desensitized using privacy enhancement techniques; For the mobile phone number field, the first three and last four digits are retained, and the middle characters are desensitized using privacy enhancement technology; For the ID number field, the first and last characters are retained, while the middle characters are desensitized using privacy enhancement technology; For bank card number or account number fields, retain the first four and last four digits, and desensitize the middle characters using privacy enhancement technology.

[0015] Based on the type of the identified sensitive fields, the corresponding desensitization rule is selected from the pre-configured set of desensitization rules, specifically: For the name field, retain the first character and replace the remaining characters with hidden symbols; For the mobile phone number field, retain the first three and last four digits, and replace the middle characters with hidden symbols; For the ID number field, retain the first and last characters, and replace the middle characters with hidden symbols; For bank card number or account number fields, retain the first four and last four digits, and replace the middle characters with hidden symbols.

[0016] The method also includes, Configure rules for identifying sensitive fields based on user permissions. The user permissions include a first user permission and a second user permission, wherein the first user permission is higher than the second user permission; Based on the first user's permissions, perform keyword matching based on the field name to determine whether the field name contains preset sensitive keywords; Based on the second user's permissions, perform keyword matching based on the field name to determine whether the field name contains preset sensitive keywords. If the field name does not contain the preset sensitive keywords and the field value meets the preset conditions, then perform regular expression pattern matching based on the field value to identify the sensitive field.

[0017] The second aspect of the present invention employs an electronic device, Including processor and memory, The memory stores a computer program that, when executed by the processor, implements the method described.

[0018] Due to the adoption of the above technical solution, the beneficial effects achieved by this invention are as follows: In this invention, by immediately traversing fields after obtaining the query result set and dynamically identifying sensitive fields based on the semantic features of the fields, the technology does not rely on a pre-configured fixed field list. It can adapt to the actual needs of dynamic changes in query result fields in banking business scenarios such as intelligent data query, identify and protect sensitive data in real time, and solve the technical problem that static desensitization rules are difficult to cover fields in dynamic result sets, thereby effectively reducing the risk of sensitive data being leaked due to desensitization omissions.

[0019] Furthermore, the system identifies sensitive fields based on their semantic features, without relying on a pre-configured list of sensitive fields. Whether a field is named according to standard or custom names, it can be uniformly identified and categorized into its corresponding sensitive type, thus applying unified desensitization rules. This significantly reduces the risk of missing desensitization data due to inconsistent field naming in cross-table queries, improving the coverage and accuracy of sensitive field identification.

[0020] Moreover, by classifying sensitive fields into various types such as name, mobile phone number, ID number, bank card number, and account number, and selecting the corresponding desensitization rule from a pre-configured set of differentiated desensitization rules based on the identified sensitive field type, the system automatically applies the most suitable differentiated desensitization strategy to different types of sensitive fields for their respective business scenarios. This ensures that the desensitized data protects sensitive information while retaining the necessary business identification and usability, achieving a good balance between data security protection and the utilization of business data value. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart illustrating the sensitive data de-identification method for banking business scenarios according to one embodiment of the present invention. Figure 2 This is a flowchart illustrating the process of identifying sensitive fields based on keyword matching according to field name in one embodiment of the present invention. Detailed Implementation

[0022] To more clearly illustrate the overall concept of the present invention, a detailed description will be provided below with reference to the accompanying drawings and examples.

[0023] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0024] like Figure 1 As shown, a sensitive data anonymization method for banking business scenarios includes: S1: Obtain the query result set and iterate through the fields in the query result set.

[0025] The main purpose of this step is to obtain the raw data before the result set enters the output chain, and to extract all field information in the result set by traversing the fields, so as to provide a data foundation for subsequent sensitive field identification and data anonymization.

[0026] Understandably, in the NL2SQL intelligent query scenario of banks, the query results are dynamically generated, and the composition of fields changes in real time depending on the user's natural language question. Therefore, it is impossible to determine in advance which fields are included in the result set, and the complete field information can only be obtained by iterating through the result set immediately after it is obtained.

[0027] In one implementation, the data masking engine receives the raw result set from the upstream query module. The raw result set is stored in a relational data table, containing several rows and columns. The data masking engine first extracts a list of field names from the result set's metadata; for example, a query result set containing customer information might contain multiple fields. Simultaneously, the data masking engine also records a sample of the data rows corresponding to each field.

[0028] During the traversal operation, field type detection is performed synchronously to determine the data type of each field. When a field's data type is string, it meets the conditions for performing regular expression pattern matching based on its value. This field is marked as a candidate field for regular expression matching, and a candidate field list is generated after the traversal is complete. If a field's data type is not string, its value cannot match the regular expression, and identification is based solely on the field name keyword. This mechanism of non-empty field values ​​and type detection effectively avoids performing invalid regular expression matching operations on numeric fields, saving system computing resources.

[0029] S2: Identify whether a field is a sensitive field based on its semantic features. The sensitive fields include at least one or more of the following types: name field, mobile phone number field, ID card number field, bank card number field, and account number field.

[0030] The main purpose of this step is to automatically determine whether a field contains sensitive information by analyzing its semantic features, without relying on a pre-configured list of fixed sensitive fields, thereby adapting to the dynamic changes in query result fields in banking scenarios.

[0031] In one implementation, the process prioritizes keyword matching of field names, followed by regular expression pattern matching of field values. Based on keyword matching of field names, it determines whether the field name contains preset sensitive keywords. Sensitive keywords are categorized into five types based on their sensitivity: name-related keywords, mobile phone number-related keywords, ID number-related keywords, bank card number-related keywords, and account number-related keywords. When a field name contains any of these categories of keywords, the field is marked as the corresponding sensitive type. The keyword matching and recognition mechanism has minimal computational overhead and can quickly process the vast majority of standard named fields.

[0032] When a field value meets preset conditions, the system performs regular expression pattern matching based on the field value for identification. Corresponding regular expression patterns are pre-configured for different types of sensitive fields.

[0033] Each sampled field value is matched against the corresponding regular expression pattern, and the percentage of successfully matched samples is counted. When the matching percentage exceeds a preset threshold (e.g., the default threshold is 80%), the field is marked as the corresponding sensitive type.

[0034] When a field value sample matches multiple regular expression patterns simultaneously, the sensitive type is determined according to the priority order of matching mobile phone number, ID card, and bank card. This method tolerates a small amount of dirty data or anomalously formatted data in the field values ​​through a proportional threshold mechanism, making it more robust to data contamination. For example, if a column that should be a mobile phone number field contains a few test data or placeholders that are not in the format of a mobile phone number, it may be missed under the binary logic of inclusion-based judgment. However, under the proportional threshold mechanism in this step, as long as more than 80% of the samples conform to the mobile phone number format, it can still be correctly identified.

[0035] This step is particularly useful for resolving the issue of data masking omissions caused by inconsistent field naming in cross-table queries. In actual banking operations, the same type of sensitive field may have multiple naming conventions in different data tables. This step identifies sensitive fields based on their semantic features, without relying on a pre-configured list of sensitive fields. Whether the field is named according to standard names or custom names, it can be uniformly identified and categorized into the corresponding sensitive type, thereby greatly reducing the risk of data masking omissions due to inconsistent field naming.

[0036] S3: Select the corresponding desensitization rule from the pre-configured desensitization rule set based on the type of the identified sensitive field.

[0037] The main purpose of this step is to automatically match the most suitable desensitization rule for different types of sensitive fields based on their varying business semantics and desensitization requirements. This ensures that sensitive information is protected while maintaining necessary data identifiability and business usability. Different types of sensitive fields have significantly different usage requirements in banking scenarios, making it difficult to simultaneously meet the needs of all parties with a uniform desensitization rule.

[0038] In one implementation, the desensitization rule set includes five desensitization rules, each corresponding to one of the five sensitive field types. The corresponding desensitization rule is applied to the name field, mobile phone number field, ID card number field, bank card number field, or account number field. The choice of desensitization rule can be determined by the identified sensitive field type.

[0039] S4: Perform field-level desensitization processing on the query result set, replacing sensitive data field by field according to the selected desensitization rules to generate a desensitized result set.

[0040] The main purpose of this step is to perform desensitization and replacement on each sensitive field in the original result set, converting the identified sensitive field content into an unreversible desensitized form, ensuring that the desensitized result set can be safely output to downstream analysis modules or end users, while not affecting the normal display of non-sensitive fields.

[0041] In one implementation, based on the list of sensitive field markers, it is determined whether the field corresponding to the column is a sensitive field. If it is a sensitive field, the desensitization rule function selected for the sensitive field type is called, passing the original value of the field as a parameter. The desensitization rule function performs string truncation, character replacement, and other operations on the original value according to a predetermined desensitization strategy, generating a desensitized string value and returning it. If it is not a sensitive field, the original value remains unchanged, and no replacement processing is performed.

[0042] In one implementation, the sensitive data de-identification method of the present invention is applied to a bank's NL2SQL intelligent query system. Users input natural language questions through the intelligent analysis interface, such as querying the names, mobile phone numbers, and ID card numbers of customers who opened accounts this month. The NL2SQL engine converts the natural language questions into structured query statements and executes them on the database, obtaining the original result set. The original result set then enters the processing flow of the present invention, sequentially executing the method, and finally outputting the de-identified result set to the user. Throughout the entire process, all sensitive fields in the original result set have been de-identified and replaced before output, ensuring that the user cannot access any of the original sensitive information. Because the identification and de-identification processes are automatically completed in the output chain, no additional user operation is required, guaranteeing a good user experience.

[0043] Compared to existing technologies, current dynamic data masking schemes, such as Chinese patent CN120995499A, use natural language processing models to identify sensitive fields and dynamically select masking strategies based on contextual scoring of user access information; however, their computational overhead due to model inference is significant. Chinese patent CN119357225A achieves masking through SQL statement rewriting, but requires pre-identification of sensitive fields and configuration of masking rules. Chinese patent CN119249485A adds masking tags when storing data, relying on storage layer preprocessing.

[0044] This invention does not rely on a pre-configured list of fixed fields, does not change the storage method of the original data, does not require rewriting SQL statements, and does not rely on model reasoning. It can complete the identification and desensitization of sensitive fields based solely on the semantic features of fields and rule matching. It is simple to implement, computationally efficient, and particularly suitable for intelligent data query scenarios with high concurrency and low latency in banks.

[0045] As a preferred embodiment of the present invention, identifying whether a field is a sensitive field based on its semantic features includes: The semantic features include field names and field values; Perform keyword matching based on field names to determine whether the field names contain preset sensitive keywords. The sensitive keywords include at least one or more of the following: name-related keywords, mobile phone number-related keywords, ID number-related keywords, bank card number-related keywords, and account number-related keywords; and / or, If the field value meets the preset conditions, then perform regular expression pattern matching based on the field value to identify sensitive fields.

[0046] Based on keyword matching by field name, five sensitive keyword mapping tables are pre-constructed, corresponding to five sensitive types: name, mobile phone number, ID card number, bank card number, and account number. For example, keywords related to name include "name," "customer name," etc.; keywords related to mobile phone number include "mobile," "phone," "phone number," etc.; keywords related to ID card number include "idno," "idcard," "certno," "ID card," "ID card number," etc.; keywords related to bank card number include "cardno," "bankcard," "card number," etc.; and keywords related to account number include "accountno," "acctno," "account number," etc.

[0047] Match the field name with the keywords mentioned above. If a certain type of keyword is matched, mark the field as the corresponding sensitive type.

[0048] As one embodiment of this implementation, keyword matching is performed based on the field name to determine whether the field name contains preset sensitive keywords, specifically as follows: Based on the frequency of banking transactions, determine the matching order for different types of sensitive keywords. Based on field names, matching is performed on different types of sensitive keywords in a predetermined matching order.

[0049] The main purpose of this embodiment is to dynamically adjust the matching order of sensitive keywords according to the differences in query load under different periods and business lines of the bank, so that the frequently occurring sensitive field types are matched first, thereby reducing the average number of matches and optimizing the performance of de-identification processing.

[0050] Specifically, during operation, the actual frequency of banking transactions appearing in queries is continuously statistically analyzed. Based on the frequency data obtained, the priority order of keyword matching is dynamically adjusted, giving priority to high-frequency and sensitive keywords in the matching judgment.

[0051] Determine the matching order for different types of sensitive keywords, specifically as follows: When the frequency of banking transactions is higher than or equal to the preset threshold, matching is performed in the following order: name-related keywords, mobile phone number-related keywords, ID number-related keywords, bank card number-related keywords, and account number-related keywords. When the frequency of banking transactions is lower than a preset threshold Matching should be performed in the following order: mobile phone number-related keywords, bank card number-related keywords, account number-related keywords, name-related keywords, and ID number-related keywords. Matching is performed in the following order: keywords related to mobile phone number, keywords related to name, keywords related to ID number, keywords related to bank card number, and keywords related to account number.

[0052] When the overall query frequency for banking transactions is detected to be higher than or equal to a preset threshold, it indicates that the system is currently in a peak business period and has higher requirements for response efficiency. At this time, matching is performed in the following order: name-related keywords, mobile phone number-related keywords, ID number-related keywords, bank card number-related keywords, and account number-related keywords. In this order, name and mobile phone number, as the most common sensitive field types in banking transactions, are prioritized for matching, which can maximize the hit rate of targets in the earlier matching steps and reduce the number of invalid matches.

[0053] It should be noted that, as Figure 2 As shown, during the sequential matching process, when a keyword is matched and identified as a sensitive field, subsequent matching stops. For example, when a field name matches a keyword related to the name and is identified as a name field, subsequent desensitization steps are executed. However, matching for keywords related to mobile phone numbers, ID card numbers, bank card numbers, and account numbers is no longer performed.

[0054] When the frequency of banking inquiries is detected to be below a preset threshold, it indicates that the current period is relatively quiet. To balance efficiency with accuracy, matching is performed in the following order: mobile phone number-related keywords, bank card number-related keywords, account number-related keywords, name-related keywords, and ID number-related keywords. The order prioritizes mobile phone number keywords, which have the highest matching accuracy and lowest overlap with other keywords, to reduce the risk of misjudgment when multiple keywords coexist. Bank card number and account number keywords are then considered. ID number keywords, due to their abbreviation (ID) being easily confused with other identifier fields, are judged last.

[0055] As an alternative, the system can also perform matching in the order of keywords related to mobile phone number, name, ID number, bank card number, and account number.

[0056] This embodiment dynamically adjusts the matching order based on business frequency, enabling the matching strategy to adapt to the query load distribution under different business scenarios of the bank. This significantly reduces the average number of matches and the de-identification processing delay during high-frequency query periods, while prioritizing recognition accuracy during low-frequency query periods, thus achieving a dynamic balance between matching efficiency and recognition accuracy.

[0057] Furthermore, identification is performed based on regular expression pattern matching of field values, and execution is carried out only when the field values ​​meet preset conditions. Since the result set size returned by different queries in the bank's intelligent query scenario varies greatly, a sampling strategy is adopted to control the computational cost of regular expression matching. When the number of rows in the result set is large, only a portion of the samples are extracted instead of the entire set being judged.

[0058] For different types of sensitive fields, corresponding regular expression patterns are pre-configured. For example, the regular expression pattern for a mobile phone number field is an 11-digit pattern starting with 1, and the regular expression pattern for an ID card number field is an 18-digit combination of numbers and letters conforming to ID card encoding rules. Sampled field values ​​are matched one by one against the corresponding regular expression pattern, and the percentage of successfully matched samples is counted. When the matching ratio exceeds a preset threshold, the field is marked as the corresponding sensitive type. When a field value sample matches multiple regular expression patterns simultaneously, the sensitivity type is determined in the following priority order: mobile phone number first, then ID card, then ID card first, then bank card.

[0059] As one embodiment of this implementation method, the field value satisfies a preset condition, specifically: The data type of the field value is string. Furthermore, the number of fields with non-empty values ​​reaches the preset minimum sample size.

[0060] The main purpose of this embodiment is to set reasonable triggering preconditions for regular expression pattern matching, avoid performing invalid regular expression matching operations on fields that are not suitable for regular expression matching, and thus effectively control computational overhead while ensuring recognition accuracy.

[0061] First, the data type of the field value must be a string. Regular expressions are tools used to describe string matching patterns; their matching objects are essentially sequences of characters. If the data type of the field is a non-string type such as numeric, date, or boolean, the value of that field cannot be effectively matched with the predefined regular expression pattern. Performing regular expression matching on such fields is neither necessary nor accurate.

[0062] Secondly, the number of fields with non-empty values ​​must reach a preset minimum sample size. Regular expression pattern matching relies on statistical analysis of the sample content of field values. If the number of available non-empty samples is too small, the confidence level of the matching statistical results will be low, insufficient to support accurate sensitive type determination. Specifically, the minimum sample size is a configurable threshold parameter, which is set by default to the smaller of 10 rows or 10% of the total number of rows in the result set. This minimum sample size setting ensures the statistical significance of the regular expression matching results, providing a reliable statistical basis for determining the matching ratio threshold.

[0063] It should be noted that regular expression matching itself has a significant computational overhead, especially in high-concurrency intelligent query scenarios in banking involving massive amounts of data, where the compilation and execution of the regular expression engine consume system resources. This embodiment effectively avoids the above-mentioned problems by setting dual conditions of data type constraints and a lower limit on sample size.

[0064] As a preferred embodiment of the present invention, field-level desensitization processing is performed on the query result set, including: Use a nested loop to traverse each row and each column of the query result set; For the current traversal position, determine whether the field corresponding to that position is a sensitive field; If it is a sensitive field, the desensitization rule function corresponding to the sensitive field type will be called to replace the original value with the desensitized value; If it is not a sensitive field, keep the original value unchanged; After the traversal is complete, output the anonymized result set.

[0065] This implementation ensures that every sensitive data in the result set is identified and replaced without changing the original values ​​of non-sensitive fields, thereby protecting sensitive information while fully preserving the usable data in the result set.

[0066] This implementation method uses a technique that iterates through each row and column, determining whether each field is a sensitive field, and then calls a selected desensitization rule function to replace each field one by one. During each iteration, the method dynamically determines the sensitive field based on its current position. When the field determination result changes, the desensitization process automatically adapts without requiring additional configuration.

[0067] Initiate a double loop traversal process. The outer loop traverses each row of the result set by row index, while the inner loop traverses each column field of the current row by column index. The column index range is from 0 to the total number of columns minus 1.

[0068] For the current traversal position, the desensitization executor first obtains the field value corresponding to that position. Then, based on the sensitive field marker list, it determines whether the field corresponding to that column position is a sensitive field. This determination is achieved by comparing whether the current column position exists in the position index field of the sensitive field marker list. If the current column position is a sensitive field, the desensitization executor calls the desensitization rule function selected for that type according to the sensitivity type in the sensitive field marker, passing the original field value as a parameter. The desensitization rule function performs string truncation, character replacement, and other operations on the original value according to the predetermined desensitization strategy, generates a desensitized string value, and returns it. Then, this desensitized value is written to the current traversal position. If the current column position is not a sensitive field, the original value remains unchanged, and no replacement processing is performed.

[0069] Once the outer loop completes its iteration, all rows in the result set have been processed, and the de-identification executor outputs the de-identified result set. The structure of this de-identified result set is identical to the original result set; only the original values ​​in sensitive fields are replaced with irreversibly de-identified values, while the values ​​of non-sensitive fields remain unchanged. This implementation performs direct replacement at the result set level, without altering the original SQL statement structure, relying on database-level de-identification capabilities, or requiring pre-added de-identification tags at the storage layer, making it easier to implement and more versatile. Furthermore, since the de-identification process is automatically completed in the result set return chain and does not depend on an external proxy server, the risk of the entire application system becoming unavailable due to proxy server failure is avoided. This de-identified result set can then be securely output to downstream analysis modules or end users, ensuring effective protection of sensitive information during the output stage.

[0070] In a preferred embodiment of the present invention, based on the type of the identified sensitive field, a corresponding desensitization rule is selected from a pre-configured set of desensitization rules, including: For the name field, the first character is retained and the remaining characters are desensitized using privacy enhancement techniques; For the mobile phone number field, the first three and last four digits are retained, and the middle characters are desensitized using privacy enhancement technology; For the ID number field, the first and last characters are retained, while the middle characters are desensitized using privacy enhancement technology; For bank card number or account number fields, retain the first four and last four digits, and desensitize the middle characters using privacy enhancement technology.

[0071] The differentiated desensitization rules take into full account the actual usage needs of different sensitive fields in banking business scenarios, achieving a balance between protecting sensitive information and maintaining data availability.

[0072] The rule of retaining the first character in name anonymization allows business personnel to use the anonymized data normally when they need to verify a customer's surname, while the given name is hidden, protecting customer privacy. For mobile phone numbers, the first three and last four digits are retained. The first three digits identify the carrier's number range, and the last four digits are a user-defined last four digits identifier; both are often indispensable in business verification scenarios. For ID card numbers, the first and last characters are retained. The retained first characters contain geographic location information, and the last characters contain a personal verification digit; both are of significant business value in compliance and traceability scenarios. For bank card or account numbers, the first four and last four digits are retained. The first four digits are the issuing bank identification code, identifying the issuing institution, and the last four digits are the account last four digits identifier; both are often needed in business processing for initial confirmation of account ownership.

[0073] Specifically, for the name field, the first character is retained and the remaining characters are replaced with hidden symbols; For the mobile phone number field, retain the first three and last four digits, and replace the middle characters with hidden symbols; For the ID number field, retain the first and last characters, and replace the middle characters with hidden symbols; For bank card number or account number fields, retain the first four and last four digits, and replace the middle characters with hidden symbols.

[0074] In one embodiment, the hidden symbol is an asterisk, and data anonymization is achieved by replacing the asterisk. It should be noted that privacy enhancement techniques are not limited to asterisk replacement, but can also be extended to various anonymization methods such as data generalization, random perturbation, or tokenization.

[0075] For example, for names, the first character is retained and then generalized to a surname plus a common placeholder. For mobile phone numbers, the first three and last four characters are retained, and the middle four characters are randomly perturbed instead of simply replaced. For ID numbers and bank card numbers, tokenization technology can be used to replace the original values ​​with meaningless substitute values ​​and achieve reversible transformation of desensitized data through mapping tables.

[0076] Taking mobile phone number anonymization as an example, in batch business verification scenarios, a consistent generalization approach can be adopted to ensure that the anonymized value of the same original mobile phone number remains consistent across different query results, facilitating cross-query data correlation analysis. This set of differentiated rules matches the most suitable anonymization strategy for different types of sensitive fields to their respective business scenarios, protecting sensitive information while retaining necessary business discernibility and usability.

[0077] In a preferred embodiment of the present invention, sensitive field identification rules are configured according to user permissions. The user permissions include a first user permission and a second user permission, wherein the first user permission is higher than the second user permission; Based on the first user's permissions, perform keyword matching based on the field name to determine whether the field name contains preset sensitive keywords; Based on the second user's permissions, perform keyword matching based on the field name to determine whether the field name contains preset sensitive keywords. If the field name does not contain the preset sensitive keywords and the field value meets the preset conditions, then perform regular expression pattern matching based on the field value to identify the sensitive field.

[0078] The main purpose of this implementation method is to adopt a differentiated sensitive field identification strategy for users with different permission levels, thereby optimizing the efficiency of system computing resource utilization while ensuring data security.

[0079] High-privilege users are typically trusted users within the bank, and their query behavior is considered highly trustworthy by default, with the system prioritizing response efficiency. Query behavior from low-privilege users or external users is considered less trustworthy, requiring the system to employ stricter identification strategies to reduce the risk of sensitive data leakage.

[0080] To achieve the above objectives, this implementation method configures the recognition depth differently based on the user's permission level. For high-privilege users with first-level user privileges, keyword matching is performed only based on the field name to determine whether the field name contains preset sensitive keywords. For low-privilege users with second-level user privileges, keyword matching based on the field name is performed first. If keyword matching fails to identify sensitive fields and the field value meets preset conditions, regular expression pattern matching is further performed based on the field value to supplement the identification of sensitive fields.

[0081] Specifically, for example, in a bank's internal intelligent analysis system, trusted users such as data governance personnel and auditors can be configured with first-level user privileges. When processing their query results, only keyword matching and identification are performed. For external query users accessing through an API gateway, they can be configured with second-level user privileges. When processing their query results, if keyword matching cannot determine the sensitive type, the system further performs regular expression pattern matching on the field values ​​to ensure that sensitive information is fully identified. The division of user privilege levels can be implemented based on the RBAC model, automatically obtaining the corresponding privilege level and determining the identification rules according to the user's role.

[0082] This implementation achieves dynamic adaptation between recognition depth and user trust level. High-privilege users are treated with a lightweight recognition strategy, reducing unnecessary computational overhead and improving response efficiency. Low-privilege users are treated with a more stringent two-level progressive recognition mechanism, supplementing the keyword matching results with regular expression validation of field values, further reducing the risk of data leakage due to unrecognized sensitive fields. This implementation extends access control to the sensitive field recognition stage, achieving a more refined balance between efficiency and security.

[0083] The second invention provides an electronic device, Including processor and memory, The memory stores a computer program that, when executed by the processor, implements the method described.

[0084] Therefore, it can achieve any effect in sensitive data desensitization methods for banking business scenarios, which will not be elaborated here.

[0085] For any parts not mentioned in this invention, existing technologies can be used or referenced.

[0086] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0087] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A method for de-identifying sensitive data in banking business scenarios, characterized in that, include: Retrieve the query result set and iterate through the fields in the query result set; Based on the semantic features of the field, it is determined whether the field is a sensitive field. The sensitive fields include at least one or more types of fields such as name, mobile phone number, ID number, bank card number, and account number. Based on the type of the identified sensitive fields, select the corresponding desensitization rule from the pre-configured desensitization rule set; The query result set is subjected to field-level desensitization processing. Sensitive data is replaced field by field according to the selected desensitization rules to generate a desensitized result set.

2. The method according to claim 1, characterized in that, Semantic feature identification based on fields determines whether a field is a sensitive field, including: The semantic features include field names and field values; Perform keyword matching based on field names to determine whether the field names contain preset sensitive keywords. The sensitive keywords include at least one or more of the following: name-related keywords, mobile phone number-related keywords, ID number-related keywords, bank card number-related keywords, and account number-related keywords; and / or, If the field value meets the preset conditions, then perform regular expression pattern matching based on the field value to identify sensitive fields.

3. The method according to claim 2, characterized in that, Keyword matching is performed based on field names to determine whether the field names contain preset sensitive keywords. Specifically: Based on the frequency of banking transactions, determine the matching order for different types of sensitive keywords. Based on field names, matching is performed on different types of sensitive keywords in a predetermined matching order.

4. The method according to claim 3, characterized in that, Based on the frequency of banking transactions, determine the matching order for different types of sensitive keywords, specifically as follows: When the frequency of banking transactions is higher than or equal to the preset threshold, matching is performed in the following order: name-related keywords, mobile phone number-related keywords, ID number-related keywords, bank card number-related keywords, and account number-related keywords. When the frequency of banking transactions is lower than a preset threshold Matching should be performed in the following order: mobile phone number-related keywords, bank card number-related keywords, account number-related keywords, name-related keywords, and ID number-related keywords. Matching is performed in the following order: keywords related to mobile phone number, keywords related to name, keywords related to ID number, keywords related to bank card number, and keywords related to account number.

5. The method according to claim 2, characterized in that, The field value meets the preset conditions, specifically: The data type of the field value is string. Furthermore, the number of fields with non-empty values ​​reaches the preset minimum sample size.

6. The method according to claim 1, characterized in that, Perform field-level data masking on the query result set, including: Use a nested loop to iterate through each row and column of the query result set; For the current traversal position, determine whether the field corresponding to that position is a sensitive field; If it is a sensitive field, the desensitization rule function corresponding to the sensitive field type will be called to replace the original value with the desensitized value; If it is not a sensitive field, keep the original value unchanged; After the traversal is complete, output the anonymized result set.

7. The method according to claim 1, characterized in that, Based on the type of the identified sensitive fields, select the corresponding desensitization rule from the pre-configured set of desensitization rules, including: For the name field, the first character is retained and the remaining characters are desensitized using privacy enhancement techniques; For the mobile phone number field, the first three and last four digits are retained, and the middle characters are desensitized using privacy enhancement technology; For the ID number field, the first and last characters are retained, while the middle characters are desensitized using privacy enhancement technology; For bank card number or account number fields, retain the first four and last four digits, and desensitize the middle characters using privacy enhancement technology.

8. The method according to claim 7, characterized in that, Based on the type of the identified sensitive fields, the corresponding desensitization rule is selected from the pre-configured set of desensitization rules, specifically: For the name field, retain the first character and replace the remaining characters with hidden symbols; For the mobile phone number field, retain the first three and last four digits, and replace the middle characters with hidden symbols; For the ID number field, retain the first and last characters, and replace the middle characters with hidden symbols; For bank card number or account number fields, retain the first four and last four digits, and replace the middle characters with hidden symbols.

9. The method according to claim 2, characterized in that, It also includes, Configure rules for identifying sensitive fields based on user permissions. The user permissions include a first user permission and a second user permission, wherein the first user permission is higher than the second user permission; Based on the first user's permissions, perform keyword matching based on the field name to determine whether the field name contains preset sensitive keywords; Based on the second user's permissions, perform keyword matching based on the field name to determine whether the field name contains preset sensitive keywords. If the field name does not contain the preset sensitive keywords and the field value meets the preset conditions, then perform regular expression pattern matching based on the field value to identify the sensitive field.

10. An electronic device, characterized in that, Including processor and memory, The memory stores a computer program that, when executed by the processor, implements the method as described in any one of claims 1 to 9.

Images