Bank data security auditing system

Abstract

The invention discloses a bank data security auditing system, and relates to the technical field of bank data security. Comprising an API interface, a security server, a security server built-in database, an interface auditing module, a data auditing module and an encryption transmission module. The API calling party is connected with the security server through an API interface; after the security server is accessed through legal authentication, a request can be submitted to the security server; the security server performs auditing through the API interface and the request thereof to determine whether the data is agreed or not, performs data auditing and clear request reply if the data is agreed, encrypts the request reply into a dynamic graph and returns the dynamic graph to the API interface, so that full-link rapid automatic auditing is realized in the aspect of timeliness, and the security of sensitive data leakage prevention is improved. High-risk fields are isolated or desensitized fundamentally through dynamic grading and strategy matching, and abuse is prevented; in the aspect of authority control, strict execution of the minimum authority principle is ensured.

Description

Technical Field

[0001] This invention relates to the field of banking data security technology, specifically to a banking data security auditing system. Background Technology

[0002] Bank data is essentially the digital lifeblood of a bank, its value far exceeding the information it presents. Banking operations are fundamentally about the deposit, withdrawal, transfer, and appreciation of funds, and all operations rely on accurate, real-time data support. Data errors or loss can directly lead to transaction failures, clearing disruptions, or accounting errors. Customers store a large amount of highly sensitive personal privacy and financial information in the banking system; its confidentiality and integrity directly affect customer rights and legal responsibilities. Therefore, bank data is of paramount importance, and its security must be effectively guaranteed. Traditional bank data security audits are conducted through internal compliance self-inspections and assessments, third-party and external evaluations, and API security protection. Compliance self-inspections and assessments involve bank employees periodically conducting self-assessments based on regulatory standards, generating gap analysis reports, and developing rectification plans. These processes are numerous and detailed, relying on manual template comparisons, which is time-consuming and prone to omissions or misjudgments due to subjective judgment. Third-party and external evaluations involve inviting authoritative security organizations to conduct penetration testing, compliance assessments, and audit certifications. These evaluations are often conducted before major deployments or annually, failing to cover daily changes. API security protection involves a comprehensive set of security controls implemented for various application programming interfaces (APIs) both internally and externally. However, this approach often involves excessive horizontal trust in backend services and loose control over external interface permissions, making sensitive data vulnerable to theft and misuse. Therefore, traditional bank data security audits suffer from poor timeliness, easy theft and misuse of sensitive data, loose access control, and insufficient automation and intelligence. Summary of the Invention

[0003] The purpose of this invention is to provide a bank data security audit system to solve the problems mentioned in the background art.

[0004] The objective of this invention can be achieved through the following technical solution: a bank data security audit system, comprising: API interface and security server: API callers connect to the security server through the API interface. The connection requires account authentication, which may include, but is not limited to, password verification, facial recognition, or fingerprint verification. After successfully authenticating and connecting to the security server, users can submit requests to the security server. The security server has a built-in database, interface auditing module, data auditing module, and encrypted transmission module. The database stores all users' bank data, which is stored in partitions according to their corresponding attributes; the bank data with different attributes is split into several data entries; at the same time, the database stores the regular expression matching relationship between each data entry and its sensitivity. The API review module performs security reviews and path scheduling on the received API requests; path scheduling includes rejection and request forwarding to the data review module. The data review module reviews the received request, outputs the corresponding bank data, and encapsulates it to send to the API interface as a response to the request. The encrypted transmission module encrypts and dynamically processes the encapsulated request and response to generate an animated image, which is then transmitted back to the API interface.

[0005] Preferably, API interface review: Extract the API interface identity properties and compare them with all set identity properties to match the corresponding permission attributes; extract the API interface request and parse its corresponding request attributes. If the request attributes match the permission attributes corresponding to the API interface identity properties, proceed to step two; otherwise, reject the API interface request for exceeding the permission attributes. Obtain API interface information, specifically including the number of times this login has been recorded in the login history (N), the IP address, and the login history records. The login history records refer to the process of submitting a request after logging in and successfully obtaining the requested bank data. If the request is rejected, it will not be counted in the login history records. Extract historical login records and match the current login information with historical login records to obtain parameters for evaluating the API interface profile, specifically including login probability, request probability, and address probability; The login count N in the historical login history, login probability Pt, request probability Pr, and address probability Pd are calculated using the formula... The raw score (raw) and the interface audit value (S) of the API interface are calculated, where θ is an adjustable bias. When raw = θ, the output S = 0.5 is determined. The corresponding path scheduling is executed according to the interface audit value.

[0006] Preferably, the fit is quantified: Extract the login time of each login from the historical login records, divide a day into 24 hour buckets, iterate through all the login times in the historical login records, and count them into the corresponding hour buckets. Convert the original counts in each hour bucket into a probability distribution to obtain the login probability of each hour bucket. Extract the login time of the current login and compare it with each hour bucket to determine the hour bucket to which it belongs and its corresponding login probability. Extract the login requests from each login in the historical login records, iterate through other API interfaces in the system with the same identity nature as this API interface, summarize their requests, classify the requests, remove the identical requests to obtain the full category of requests corresponding to this identity nature; iterate through the historical login requests of this API interface and count them into the full category of requests, then convert the original count of the full category of requests into request probabilities, extract the request of this login, and compare it with the full category of requests to match the corresponding request probability; Extract the IP address of each login from the historical login records, iterate through all historical login IP addresses and remove duplicates to obtain an IP address list, count the IP address of each login from the historical login records into the IP address list, convert the original count of each IP address in the IP address list into the address probability of each IP address, extract the IP address of the current login, and compare it with the historical IP addresses to match the corresponding address probability.

[0007] Preferably, path scheduling: If the API's security value exceeds the maximum value of the security range, the API request will be forwarded to the data audit module. If the API's security value is within the security range, a re-verification request will be sent to the API. If the verification passes, the API request will be forwarded to the data audit module. If the verification fails three times, the request will be rejected. If the API's security value is less than the minimum value of the security range, the request will be rejected because the API is considered to be too risky.

[0008] Preferably, data verification: Extract API requests and use semantic parsing to transform them into structured query intent objects, clarifying the data needed by the user and the entities involved in the request. Based on the query intent object, retrieve all relevant data from the database as the request data. For example, if the query intent corresponds to transaction records within the last 7 days, retrieve all loan records and repayment records for the last month. Then, divide the retrieved request data into several data bars according to a sharding principle, and compare each data bar with a pre-defined sensitivity regular expression to obtain the sensitivity of each data bar. A preset sensitivity threshold is set; if the sensitivity of a data bar is greater than or equal to the threshold, it is marked as a highly sensitive data bar. Count the number of highly sensitive data bars in the request data and divide it by the total number of data bars in the request data to obtain the percentage of highly sensitive data bars. Extract the API security value. If S ≥ 0.9 and the proportion of highly sensitive data ≤ 0.3, return the entire field as a request response without data deletion or modification. If 0.7 ≤ S < 0.9 or the proportion of highly sensitive data > 0.3, return the anonymized field as a request response. Otherwise, only return metadata as a request response. Specifically, returning the entire field means extracting the complete request data without any processing and encapsulating it as a request response. Field anonymization means obfuscating (not displaying) the values ​​in highly sensitive data fields in the request data and encapsulating it as a request response. Returning only metadata means obfuscating the values ​​contained in all data fields in the request data, only indicating the field structure or existence, and encapsulating it as a request response.

[0009] Preferably, the animated image is generated through encryption and dynamic processing: Step 1: Remove all unnecessary spaces, newlines, indentation, etc. from the request response, keeping only the minimum parsable structure to obtain a plain text. Map the characters in the plain text to a preliminary sequence according to the UTF-8 rule. Use Hex encoding to split each byte in the preliminary sequence into two hexadecimal characters to obtain a character sequence. Step 2: Divide the character sequence into n subsequences. If the length of a subsequence is insufficient, expand it until the minimum number of bytes is met. Step 3: Set up a W×H grid canvas, where W is the number of columns and H is the number of rows, and each square is equivalent to a pixel block; select one subsequence and fill the canvas with the bytes of the subsequence to form a snowflake image; Step four: Repeat steps one and three above for each of the n subsequences to generate corresponding snowflake images, and arrange them sequentially according to the order of the subsequences in the character sequence to form a frame sequence. Each frame is set with a duration, thus forming an animated file. This animated file is sent to the API interface as a visual encrypted carrier of data. When the API interface receives the corresponding animated file, the API interface completes a full login and stores it in the login record.

[0010] Preferably, the expansion when the subsequence byte length is insufficient is as follows: The character sequence is divided into n segments of equal length. If the last segment is insufficient, it is padded with empty spaces or looped back to obtain n subsequences. For each subsequence, it is split into two bytes to obtain a byte stream. If the length of the byte stream is less than the minimum number of bytes, a new pseudo-random output of 32 bytes is obtained by hash expansion and this output is directly appended to the original byte stream. After appending, if the required length is still not reached, the new, expanded byte stream is hash expanded again and appended in the same way until the length of the entire byte stream is at least equal to the minimum number of bytes.

[0011] Preferably, the canvas is filled to form a snowflake image: Filling: Unfold the cells into a linear list, in the order of column 0 to column ⌈W / 2⌉−1 of the first row, then the same column interval of the second row, and so on, up to the Hth row; when traversing each cell, take one byte from the subsequence in turn. If the highest bit of this byte is 1, the instruction corresponding to this cell is to light it up, i.e., fill it. If the highest bit of this byte is 0, keep it empty, i.e. blank; after all cells on the left half have been monitored according to the highest bit, flip the filling state of the right half left and right and copy it to the right. Coloring: Take the first three bytes of the subsequence, form a hexadecimal number with each pair of characters, convert it to decimal to get three color components: R, G, and B. These color components constitute the main color tone, and fill the cells of the fill instruction according to this main color tone. Color adjustment: Take the byte corresponding to the cell, extract the lower 6 bits of the byte, and map them to the preset value and the fine-tuning relationship of transparency to obtain the transparency of each cell. Thus, all cells share the same main color, and each cell has its own transparency, which is then adjusted.

[0012] The beneficial effects of this invention are: 1. A dynamic and evolvable interface behavior profile was established through multi-dimensional behavioral feature assessment (including login frequency, login time distribution, request type distribution, and historical IP preferences). Probabilistic modeling and non-linear risk amplification mechanisms were introduced to convert the consistency between historical and real-time behaviors into quantifiable interface security values, significantly improving the sensitivity and stability of abnormal behavior identification. Interface security intervals were set to implement a risk-based tiered processing mechanism: highly trustworthy requests are automatically allowed, medium-risk requests require secondary verification, and extremely high-risk requests are directly rejected, effectively preventing issues such as permission overreach and unauthorized data access. This represents a comprehensive upgrade from identity verification to behavioral trust assessment, greatly enhancing the security and controllability of bank data interface calls.

[0013] 2. By ensuring data availability, a multi-level data access mechanism based on sensitivity was constructed. First, the original data entries are semantically parsed and structurally split to accurately extract the request intent and construct corresponding queries, ensuring that data is retrieved on demand. Second, each data entry is compared with a predefined sensitivity matching relationship, and the proportion of highly sensitive data is calculated. Then, a data audit strategy is formulated in conjunction with the API interface security value. These three mechanisms together realize the principle of minimum data disclosure: requests with high trust and low sensitivity can return the full data, requests with medium trust or high sensitivity will return de-identified data, and requests with excessive risk will only return metadata. This not only effectively prevents the leakage of sensitive information but also takes into account business processing efficiency and compliance requirements.

[0014] 3. By introducing a visual encryption mechanism that generates snowflake images based on data content, the system overcomes the risks of hijacking, forgery, or replay attacks that may exist with traditional static keys or SSL transmission encryption. The request data is converted into a character sequence after being transcoded into UTF-8 and hexadecimal. The character sequence is then hashed and graphically encoded, ultimately transforming into a snowflake animation image with symmetrical patterns and dynamic color adjustments. Each frame of the image is strictly driven by the original data, possessing a high degree of uniqueness and verifiability. Even if a hacker intercepts the image, it is difficult to deduce the original data or forge a compliant image. In addition, the continuity of the frame animation constitutes a natural timestamp protection, further increasing the data's resistance to tampering. This not only enhances the security strength of the data during transmission but also endows the data with high auditability and traceability, greatly improving the protection level throughout the entire data lifecycle. Attached Figure Description

[0015] The invention will now be further described with reference to the accompanying drawings.

[0016] Figure 1 This is a schematic diagram of the system module connections of the present invention; Figure 2 This is a schematic diagram of the review process of the interface review module of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Please see Figure 1 As shown, this invention is a bank data security audit system, including: an API interface and a security server. The security server has a built-in database, an interface audit module, a data audit module, and an encrypted transmission module. The API caller connects to the security server through the API interface, and the connection requires account authentication, which includes, but is not limited to, password verification, facial recognition, or fingerprint verification. After successfully authenticating and accessing the security server, the API caller can submit a request to the security server. The API interface (API caller account) corresponds to different identity types, and different identity types correspond to different permission attributes. For example, if the identity type of the API caller account is loan service, then its corresponding permission attribute is the loan service permission attribute, that is, it can only access and operate data related to loan business. The database stores all users' bank data confidentially. It should be noted that the users' bank data consists of entity business with different attributes, including customer files, transaction records, loan information, etc. The bank data with different attributes is split into several data entries. When segmenting the bank data, the following principles are maintained: (1) field-level minimization, (2) business semantic association, and (3) dynamic combination capability. All data entries are subjected to operations such as noise reduction, unified encoding, date standardization, and number normalization to ensure the consistency of subsequent rules and model inputs. Context information, data source, and timestamp are attached to each unit. The database pre-stores the regular expression matching relationship between each data entry and its sensitivity. For example, the sensitivity of transaction information is 5, the sensitivity of ID card number and bank card number is 4, the sensitivity of mobile phone number and email is 3, etc. When a data entry's field does not belong to any data entry in the regular expression matching relationship, it indicates that this data entry is non-sensitive data. like Figure 2 As shown, the API review module is located between the API gateway and the backend service. All API calls must first pass through this module. Based on the received API requests, it performs security reviews and path scheduling on the APIs; specifically: Step 1: Extract the API interface identity type and compare it with all set identity types to match the corresponding permission attributes; extract the API interface request and parse its corresponding request attributes. If the request attributes match the permission attributes corresponding to the API interface identity type, proceed to Step 2; otherwise, reject the API interface request for exceeding the permission attributes. Step two involves obtaining API interface information, specifically including the number of times this login has appeared in the login history (denoted as N), the IP address, and the number of login records. For example, if this login has appeared 5 times in the login history, it means this is the fifth login. The more logins, the more times the system has accessed bank data, and the higher the level of trust. It should be noted that the login history records here refer to the process of submitting a request after logging in and successfully obtaining the requested bank data. If the request is rejected, it will not be counted in the login history records. Step 3: Extract the login time of each login from the historical login records, and divide the 24 hours of a day into 24-hour buckets. Specifically, 0:00–0:59 is bucket 0, 1:00–1:59 is bucket 1, and so on. Iterate through all the login times in the historical login records and count them into their corresponding hour buckets. Convert the original counts in each hour bucket into a probability distribution to obtain the login probability of each hour bucket. Extract the login time of the current login and compare it with each hour bucket to determine its hour bucket and its corresponding login probability, denoted as Pt. It should be noted that the higher this login probability, the more the login conforms to the login habits of the API interface. Step 4: Extract the requests for each login from the historical login records. Iterate through other API interfaces in the system with the same identity type as this API interface, summarize their requests, and classify the requests. Remove the duplicate requests to obtain the full request category corresponding to this identity type. Iterate through the historical login requests of this API interface and count them into the full request category. Then, convert the original count of the full request category into a request probability. Extract the request for this login and compare it with the full request category to match the corresponding request probability, which is recorded as Pr. It should be noted that the higher this request probability, the more the login request conforms to the request habits of the API interface. Step 5: Extract the IP address of each login from the historical login records. Iterate through all historical login IP addresses and remove duplicates to obtain an IP address list. Count the IP address of each login in the historical login records into the IP address list. Then, convert the original count of each IP address in the IP address list into the address probability of each IP address. Extract the IP address of the current login and compare it with the historical IP addresses to match the corresponding address probability, denoted as Pd. It should be noted that the higher this address probability, the more the IP address of the current login matches the caller's historical login habits. Step 6: Calculate the number of logins N in the historical login history, login probability Pt, request probability Pr, and address probability Pd according to the formula... The raw score (raw) and interface audit value (S) of the API interface are calculated, where θ is an adjustable bias. When raw = θ, the output S = 0.5. The formula shows that if factors such as the number of logins N, login probability Pt, request probability Pr, and address probability Pd increase, then the larger the raw score and the larger the S value, indicating a more secure API interface. This formula design uses non-linear amplification of logarithmic transformation and smooth truncation of the sigmoid mapping. The non-linear amplification of the logarithmic function has a very strong slope for small values ​​(risk factors close to 0): when a certain factor... When the risk factor is very low, the logarithmic transformation will produce a large negative value, thus significantly lowering the overall raw value. At the same time, the logarithm tends to flatten at high values ​​(close to 1), avoiding excessive amplification of high-frequency routine behaviors. It penalizes and amplifies low-confidence factors and smooths the rewards for high-confidence factors. The smooth truncation of the Sigmoid mapping: mapping the raw value to the [0,1] interval, takes into account both numerical comparability and natural connection with the threshold decision commonly used in business. By adjusting the bias θ, it is possible to flexibly set which raw value is considered to be 0.5 points - that is, where the critical point of medium risk is considered. The Sigmoid converges at the tail and has a flattening effect on extreme raw values ​​(very large or very small), avoiding the loss of control due to the decision exceeding the range. Combining the small value amplification of the logarithm with the controllable convergence of the Sigmoid, it can amplify abnormal factors to improve detection sensitivity and smooth high values ​​to avoid excessive trust impacting business. The API security range [L, H] is set. If the API security value is greater than the maximum value H of the security range, it indicates that the current call is highly consistent with past habits in terms of historical behavior and real-time characteristics, and the risk is extremely low. In this case, the API request is forwarded to the data audit module. If the API security value is within the security range [L, H], it indicates that the API request has a certain risk and requires secondary verification. In this case, a re-verification request is sent to the API. If the verification passes, the API request is forwarded to the data audit module. If the verification fails three times, the request is rejected. If the API security value is less than the minimum value L of the security range, it indicates that the API request has an extremely high risk and a significant security vulnerability. In this case, the request is rejected because the API risk is too high. By conducting multi-dimensional behavioral feature assessments (including login frequency, login time distribution, request type distribution, and historical IP preferences), a dynamic and evolvable interface behavior profile was established. Probabilistic modeling and a non-linear risk amplification mechanism were introduced to convert the consistency between historical and real-time behavior into a quantified interface security value, significantly improving the sensitivity and stability of abnormal behavior identification. An interface security range was set, implementing a risk-based tiered processing mechanism: highly trustworthy requests are automatically allowed, medium-risk requests require secondary verification, and extremely high-risk requests are directly rejected. This effectively prevents issues such as permission overreach and unauthorized data access, achieving a comprehensive upgrade from identity verification to behavioral trust assessment, greatly enhancing the security and controllability of bank data interface calls.

[0019] The data verification module verifies the data received from the API interface request, outputs the corresponding bank data, and encapsulates it to send to the API interface as a response; specifically: Extract API requests and use semantic parsing to transform them into structured query intent objects, clarifying the data needed by the user and the entities involved in the request. Based on the query intent object, retrieve all relevant data from the database as the request data. For example, if the query intent corresponds to transaction records within the last 7 days, retrieve all loan records and repayment records for the last month. Then, divide the retrieved request data into several data bars according to a sharding principle, and compare each data bar with a pre-defined sensitivity regular expression to obtain the sensitivity of each data bar. A preset sensitivity threshold is set; if the sensitivity of a data bar is greater than or equal to the threshold, it is marked as a highly sensitive data bar. Count the number of highly sensitive data bars in the request data and divide it by the total number of data bars in the request data to obtain the percentage of highly sensitive data bars. Extract the API interface security value. If S ≥ 0.9 and the proportion of highly sensitive data ≤ 0.3, return the entire field as a request response without data deletion or modification. If 0.7 ≤ S < 0.9 or the proportion of highly sensitive data > 0.3, return the anonymized field as a request response. In other cases, only the metadata is returned as a request response. Specifically, returning the entire field means extracting the complete request data without any processing and encapsulating it as a request response. Field anonymization means obfuscating the values ​​in highly sensitive data fields in the request data (i.e., not displaying them) and encapsulating them as a request response. Returning only metadata means obfuscating the values ​​contained in all data fields in the request data, only indicating the field structure or existence, and encapsulating it as a request response. By ensuring data availability, a multi-layered data access mechanism based on sensitivity was constructed. First, the original data entries are semantically parsed and structurally broken down to accurately extract the request intent and construct corresponding queries, ensuring that data is retrieved on demand. Second, each data entry is compared with a predefined sensitivity matching relationship, and the proportion of highly sensitive data is calculated. Then, a data audit strategy is formulated in conjunction with the API interface security value. These three mechanisms together realize the principle of minimum data disclosure: requests with high trust and low sensitivity can return the full data, requests with medium trust or high sensitivity will return anonymized data, and requests with excessive risk will only return metadata. This not only effectively prevents the leakage of sensitive information but also takes into account business processing efficiency and compliance requirements.

[0020] The encrypted transmission module transmits the encapsulated request and response in encrypted form to the corresponding API interface, specifically as follows: Step one: Remove all unnecessary spaces, newlines, indentation, etc., from the request response, retaining only the minimum parsable structure to obtain a plain text. Map the characters in the plain text to a preliminary sequence according to the UTF-8 rules. UTF-8 is currently the most widely used character encoding method on the Internet, which can represent almost all the world's written characters with 1 to 4 bytes. Use Hex (hexadecimal) encoding to split each byte in the preliminary sequence into two hexadecimal characters (i.e., 0-9, af) to obtain a character sequence. As can be seen from the above transcoding process, at this time, the character sequence only retains numbers and letters. Step 2: Set the number of segments n, where n is a positive integer; cut the character sequence into n equal segments, padding the last segment if it is insufficient or looping back to obtain n subsequences; for each subsequence, split it into one byte for every two characters, obtaining a byte stream; if the length of the byte stream is less than the minimum number of bytes, use hash expansion to obtain a new 32-byte pseudo-random output, and append this output directly to the original byte stream. After appending, if the required length is still not reached, hash expansion is performed again on the new, expanded byte stream, and appending is done in the same way; this hash-append-hash-append cycle continues until the length of the entire byte stream is at least equal to the minimum number of bytes required by the grid; hash expansion is to ensure that the length of each subsequence is sufficient for graphic transformation; Step 3: Set up a W×H grid canvas, where W is the number of columns and H is the number of rows, and each square represents a pixel block; select a subsequence and fill the canvas with the bytes of the subsequence to form a snowflake image, specifically: Filling: Each byte in each subsequence carries a fill instruction, that is, the highest bit of the byte (i.e., the 7th bit in binary) determines whether to fill; due to the symmetry of the snowflake image, we only need to focus on the first ⌈W / 2⌉ columns of the left half, and flatten these cells into a linear list, in the order of column 0 to column ⌈W / 2⌉−1 of the first row, then the same column interval of the second row, and so on, up to the H row; when traversing each cell, take one byte from the subsequence in turn. If the highest bit of this byte is 1, then the instruction for this cell is to light up; if the highest bit of this byte is 0, then keep it empty; after all the cells in the left half have been monitored according to the highest bit, then flip the fill state of the right half left and right and copy it to the right. In this way, the snowflakes corresponding to the subsequences on the canvas have a perfect horizontal symmetry effect; Coloring: Take the first three bytes of the subsequence, form a hexadecimal number with each pair of characters, convert it to decimal to obtain three color components: R, G, and B. This color component constitutes the primary color tone. Fill the cells in the fill instruction according to this primary color tone, and the cells become the basic color of the snowflake. For example, if the first three bytes of the subsequence are "0xA3", "0xF1", and "0xC8", "0xA3" is 163 in decimal, which is the red channel; "0xF1" is 241 in decimal, which is the green channel; and "0xC8" is 200 in decimal, which is the blue channel. It should be noted that RGB is a color representation method, composed of three color channels: red (R), green (G), and blue (B). The value range of each channel is 0 to 255, which can be represented by one byte (1 byte = 8 bits, maximum value 255). Color adjustment: Take the byte corresponding to the cell, extract the lower 6 bits of the byte (that is, the rightmost 6 bits of the byte are binary values), and map this value between 0 and 63 to the preset value and the fine-tuning relationship of transparency to obtain the transparency of each cell. Thus, although all cells share the same main color, the semi-transparency of each cell is slightly different: the larger the number, the fuller it is; the smaller the number, the more transparent it is. As a result, each petal of the snowflake retains the unity of the overall color, but also has subtle variations in shade, looking like real ice crystals shining under the light, both regular and layered. Whether each cell is filled or not does not depend on artificial patterns or random numbers, but comes entirely from the bytes in that sequence: the highest bit determines whether to fill, thus using the same original data to drive the distribution of snowflake petals and ensure the consistency and reproducibility of the pattern. Step 4: Repeat steps 1 and 3 above for each of the n subsequences to generate corresponding snowflake images, and arrange them sequentially according to the order of the subsequences in the character sequence to form a frame sequence. Each frame is set to a duration of 200ms, which is equivalent to a playback frame rate of 5 frames per second. This forms an animated file, which is then sent to the API interface as a data visualization and encryption carrier. When the API interface receives the corresponding animated file, the API interface completes a full login and stores it in the login record. By introducing a visual encryption mechanism that generates snowflake images based on data content, the risk of hijacking, forgery, or replay attacks that may exist in traditional static key or SSL transmission encryption is broken. The request data is converted into a character sequence after being transcoded into UTF-8 and hexadecimal, and then the character sequence is hashed and graphically encoded, and finally transformed into a snowflake animation image with symmetrical patterns and dynamic color adjustment. Each frame of the image is strictly driven by the original data and has a high degree of uniqueness and verifiability. Even if a hacker intercepts the image, it is difficult to deduce the original data or forge a compliant image. In addition, the continuity of the frame animation constitutes a natural timestamp protection, which further increases the data's resistance to tampering. This not only enhances the security of the data in the transmission process, but also gives the data a high degree of auditability and traceability, greatly improving the protection level of the data throughout its entire life cycle.

[0021] The above description is merely an example and illustration of the structure of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the structure of the invention or exceed the scope defined in the claims, all of which should fall within the protection scope of the present invention.

Claims

1. A bank data security auditing system, comprising: API interface and security server. API callers connect to the security server through the API interface. The connection requires account authentication, which may include, but is not limited to, password verification, facial recognition, or fingerprint verification. After successfully authenticating and accessing the security server, users can submit requests to the security server. The security server is characterized by having a built-in database, interface auditing module, data auditing module, and encrypted transmission module. The database stores all users' bank data, which is stored in partitions according to their corresponding attributes; the bank data with different attributes is split into several data entries; at the same time, the database stores the regular expression matching relationship between each data entry and its sensitivity. The API review module performs security reviews and path scheduling on the received API requests; path scheduling includes rejection and request forwarding to the data review module. The data review module reviews the received request, outputs the corresponding bank data, and encapsulates it to send to the API interface as a response to the request. The encrypted transmission module encrypts and dynamically processes the encapsulated request and response to generate an animated image, which is then transmitted back to the API interface.

2. The bank data security auditing system according to claim 1, characterized in that, API interface review: Extract the API interface identity properties and compare them with all set identity properties to match the corresponding permission attributes; extract the API interface request and parse its corresponding request attributes. If the request attributes match the permission attributes corresponding to the API interface identity properties, proceed to step two; otherwise, reject the API interface request for exceeding the permission attributes. Obtain API interface information, specifically including the number of times this login has occurred in the login history (denoted as N), the IP address, and the login history records. The login history records refer to the process of submitting a request after logging in and successfully obtaining the requested bank data. If the request is rejected, it will not be recorded in the login history. Extract historical login records and match the current login information with historical login records to obtain parameters for evaluating the API interface profile, specifically including login probability, request probability, and address probability; The original score and interface review value of the API interface are obtained by formulaically calculating and analyzing the number of logins, login probability, request probability and address probability of this login in the history, and the corresponding path scheduling is executed according to the interface review value.

3. The bank data security auditing system according to claim 2, characterized in that, Fit Quantification: Extract the login time of each login from the historical login records, divide a day into 24 hour buckets, iterate through all the login times in the historical login records, and count them into the corresponding hour buckets. Convert the original counts in each hour bucket into a probability distribution to obtain the login probability of each hour bucket. Extract the login time of the current login and compare it with each hour bucket to determine the hour bucket to which it belongs and its corresponding login probability. Extract the login requests from each login in the historical login records, traverse other API interfaces in the system with the same identity nature as this API interface, summarize their requests, classify the requests, and remove the identical requests to obtain the full category of requests corresponding to this identity nature; Iterate through the historical login requests of this API interface and count them into the full request category. Then convert the original count of the full request category into a request probability. Extract the request for this login and compare it with the full request category to match the corresponding request probability. Extract the IP address of each login from the historical login records, iterate through all historical login IP addresses and remove duplicates to obtain an IP address list, count the IP address of each login from the historical login records into the IP address list, convert the original count of each IP address in the IP address list into the address probability of each IP address, extract the IP address of the current login, and compare it with the historical IP addresses to match the corresponding address probability.

4. A bank data security auditing system according to claim 3, characterized in that, Path scheduling: If the API's security value exceeds the maximum value of the security range, the API request will be forwarded to the data audit module. If the API's security value is within the security range, a re-verification request will be sent to the API. If the verification passes, the API request will be forwarded to the data audit module. If the verification fails three times, the request will be rejected. If the API's security value is less than the minimum value of the security range, the request will be rejected because the API is considered to be too risky.

5. A bank data security auditing system according to claim 4, characterized in that, Data review: Extract the API interface request and use semantic parsing to transform it into a structured query intent object. Based on the query intent object, retrieve all the relevant data from the database as the request data. Then, divide the retrieved request data into several data bars according to the sharding principle, and compare them with the preset regular expression matching relationship between each data bar and the sensitivity to obtain the sensitivity corresponding to each data bar in the request data. A preset sensitivity threshold is set. If the sensitivity of a data bar is greater than or equal to the sensitivity threshold, it is marked as a highly sensitive data bar. The number of high-sensitivity data bars in the request data is counted, and then divided by the total number of data bars in the request data to obtain the high-sensitivity percentage. Extract the API interface security value. If S ≥ 0.9 and the proportion of highly sensitive data ≤ 0.3, return the entire field as a request response without any data deletion or modification. If 0.7 ≤ S < 0.9 or the proportion of highly sensitive data > 0.3, return the field after anonymization as a request response. In other cases, only return the metadata as a request response. Specifically, returning the entire field means extracting the complete request data without any processing and encapsulating it as a request response. Field anonymization means obfuscating the values ​​in the highly sensitive data entries in the request data and encapsulating them as a request response. Returning only metadata means obfuscating the values ​​contained in all data entries in the request data, only indicating the field structure or existence, and encapsulating it as a request response.

6. A bank data security auditing system according to claim 5, characterized in that, Encryption and dynamic processing to generate animated GIFs: Step 1: Remove all unnecessary spaces, newlines, indentation, etc. from the request response, keeping only the minimum parsable structure to obtain a plain text. Map the characters in the plain text to a preliminary sequence according to the UTF-8 rule. Use Hex encoding to split each byte in the preliminary sequence into two hexadecimal characters to obtain a character sequence. Step 2: Divide the character sequence into n subsequences. If the length of a subsequence is insufficient, expand it until the minimum number of bytes is met. Step 3: Set up a W×H grid canvas, where W is the number of columns and H is the number of rows, and each square is equivalent to a pixel block; select one subsequence and fill the canvas with the bytes of the subsequence to form a snowflake image; Step four: Repeat steps one and three above for each of the n subsequences to generate corresponding snowflake images, and arrange them sequentially according to the order of the subsequences in the character sequence to form a frame sequence. Each frame is set with a duration, thus forming an animated file. This animated file is sent to the API interface as a visual encrypted carrier of data. When the API interface receives the corresponding animated file, the API interface completes a full login and stores it in the login record.

7. A bank data security auditing system according to claim 6, characterized in that, When the subsequence byte length is insufficient, the expansion is as follows: The character sequence is divided into n segments of equal length. If the last segment is insufficient, it is padded with empty spaces or looped back to obtain n subsequences. For each subsequence, it is split into two bytes to obtain a byte stream. If the length of the byte stream is less than the minimum number of bytes, a new pseudo-random output of 32 bytes is obtained by hash expansion and this output is directly appended to the original byte stream. After appending, if the required length is still not reached, the new, expanded byte stream is hash expanded again and appended in the same way until the length of the entire byte stream is at least equal to the minimum number of bytes.

8. A bank data security auditing system according to claim 7, characterized in that, Canvas fill forms a snowflake image: Filling: Unfold the cells into a linear list, in the order of column 0 to column ⌈W / 2⌉−1 of the first row, then the same column interval of the second row, and so on, up to the Hth row; when traversing each cell, take one byte from the subsequence in turn. If the highest bit of this byte is 1, the instruction corresponding to this cell is to light it up. If the highest bit of this byte is 0, keep it empty; after all cells on the left half have been monitored according to the highest bit, flip the filling state of the right half left and right and copy it to the right. Coloring: Take the first three bytes of the subsequence, form a hexadecimal number with each pair of characters, convert it to decimal to get three color components: R, G, and B. These color components constitute the main color tone, and fill the cells of the fill instruction according to this main color tone. Color adjustment: Take the byte corresponding to the cell, extract the lower 6 bits of the byte, and map them to the preset value and the fine-tuning relationship of transparency to obtain the transparency of each cell. Thus, all cells share the same main color, and each cell has its own transparency, which is then adjusted.

Images