A credit granting processing method, electronic device and computer readable medium

Abstract

The application discloses a credit granting processing method, an electronic device and a computer readable medium, and relates to the technical field of credit granting processing, which comprises the following steps: acquiring customer data of a to-be-credited customer, and storing the customer data into a synchronization table; performing integrity check, format legality check and distribution consistency check on the customer data in the synchronization table to obtain a customer data check result; in the case that the customer data check result is passed, synchronizing the customer data in the synchronization table to a business table; performing access check on the customer data in the business table by using a pre-access decision rule to obtain a pre-access result of the to-be-credited customer; and in the case that the pre-access result of the to-be-credited customer is passed, performing a credit granting operation on the to-be-credited customer. The application can avoid production accidents when performing access operation and credit granting operation on a customer.

Description

Technical Field

[0001] This invention relates to the field of credit processing technology, specifically to a credit processing method, electronic device, and computer-readable medium. Background Technology

[0002] Currently, in financing and credit risk control systems, financial institutions typically rely on daily batch pushes of customer operating indicators, risk tags, and other data from quantitative big data platforms to perform customer access assessments and credit limit calculations. Existing technologies generally employ the following process: After the quantitative platform completes the quantitative calculation of customer data, it directly synchronizes the quantified customer data to the risk control business database table. Subsequently, the risk control system immediately initiates a full batch processing task, making access and credit granting decisions for all customers based on the pushed customer data.

[0003] However, if the pushed customer data is directly entered into the business table and triggers formal batch processing, it may cause a large number of errors in the admission results and credit limits of a large number of customers, thereby causing production accidents. Summary of the Invention

[0004] This invention aims to address, to a certain extent, one of the technical problems in related technologies. To this end, this invention provides a credit processing method, an electronic device, and a computer-readable medium, which have the advantage of avoiding production accidents during customer access and credit granting operations.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: A credit processing method, comprising: Obtain customer data of customers to be granted credit, and store the customer data in a synchronization table; The customer data in the synchronization table is subjected to integrity verification, format validity verification, and distribution consistency verification to obtain the customer data verification results. If the customer data verification result is successful, the customer data in the synchronization table will be synchronized to the business table; The customer data in the business table is verified using the pre-admission decision rules to obtain the pre-admission result of the customer to be granted credit. If the pre-approval result of the customer to be granted credit is approved, the credit granting operation is performed on the customer to be granted credit.

[0006] Optionally, the step of performing integrity verification, format validity verification, and distribution consistency verification on the customer data in the synchronization table to obtain the customer data verification result includes: The customer data in the synchronization table is subjected to integrity verification, format validity verification, and distribution consistency verification to obtain integrity verification results, format validity verification results, and distribution consistency verification results. If the integrity verification result, the format validity verification result, and the distribution consistency verification result are all passed, the customer data verification result is determined to be passed.

[0007] Optionally, the step of performing integrity verification, format validity verification, and distribution consistency verification on the customer data in the synchronization table to obtain integrity verification results, format validity verification results, and distribution consistency verification results includes: If the difference between the number of data rows in the synchronization table and the average number of rows in the preset time period does not exceed the preset difference, and the null value rate of the customer identifier in the synchronization table is not greater than the preset null value rate, the integrity verification result is passed. If the total transaction amount of all the customers to be granted credit in the synchronization table is not less than the preset amount, and the transaction identification information in the synchronization table is not duplicated, the format legality verification result is passed; If all numerical customer data metrics are within their corresponding preset ranges in the synchronization table, the distribution consistency check result is passed.

[0008] Optionally, the step of using pre-admission decision rules to perform admission verification on the customer data in the business table to obtain the pre-admission result of the customer to be granted credit includes: Determine the pre-access rule identifier corresponding to the credit product of the customer to be granted credit; Determine the pre-admission decision rule corresponding to the pre-admission rule identifier; The business feature values ​​corresponding to each of the pre-admission decision rules are extracted from the business table using the pre-admission rule identifier. Replace the feature placeholders in the expression of the pre-admission decision rule with the corresponding business feature values ​​to obtain the pre-admission decision rule expression; For each of the pre-admission decision rule expressions, a decision judgment is made to obtain the decision result corresponding to each of the pre-admission decision rule expressions; If all the aforementioned decision results are passed, the pre-admission result of the customer to be granted credit is determined to be passed.

[0009] Optionally, the business table corresponds to a business data type, the business data type corresponds one-to-one with a business data code, the business data code corresponds to multiple feature codes, the feature codes correspond one-to-one with Groovy scripts, and the Groovy scripts are used to convert the business data corresponding to the feature codes into business feature values. The step of extracting the business feature values ​​corresponding to each of the pre-admission decision rules from the business table using the pre-admission rule identifier includes: Determine the business data code corresponding to the pre-admission rule identifier, and the feature code corresponding to the business data code; Using the customer identifier of the customer to be granted credit and the business data code, read the corresponding business data from the corresponding business table; The Groovy script corresponding to the feature code is invoked to convert the corresponding business data into business feature values.

[0010] Optionally, the step of reading the corresponding business data from the corresponding business table using the customer identifier of the customer to be granted credit and the business data code includes: When the business data type corresponding to the business data code is list configuration data, the data warehouse interface is called to extract the corresponding list configuration identifier from the list configuration warehouse based on the customer identifier; wherein, the list configuration warehouse is a mapping table consisting of the customer identifier and the list configuration identifier.

[0011] Optionally, the step of granting credit to the customer who is to be granted credit if the pre-approval result is approved includes: Store the pre-approval results of each of the aforementioned customers awaiting credit in the pre-approval result table; The percentage of candidates who passed the pre-admission result in the pre-admission result table is determined as the first proportion. The current effective official admission results table determines the second percentage of admissions passed. If the difference between the first percentage and the second percentage is less than a preset threshold, the credit granting operation is performed on the customers whose pre-approval result is passed, and the formal admission result table is updated using the pre-approval result table. Credit granting operations will be performed on the approved customers pending credit granting results in the updated official admission results table.

[0012] Optionally, the step of performing credit granting operations on the approved customers in the updated official access result table includes: Determine the credit code corresponding to the credit product of the customer to be granted credit, the credit data code corresponding to the credit code, and the data parsing script; The data center is invoked based on the credit data encoding, and the data center collects the original credit data based on the data source encoding and customer identifier. The raw credit data is converted into standardized data objects using the data parsing script. The current credit limit is determined using the standardized data object and the credit granting logic corresponding to the credit granting code; Store the current credit limit and the customer identifier of the customer to be granted credit in the pre-credit result table; For customers awaiting credit granting who already have credit limits in the pre-credit granting result table, if the proportion of customers awaiting credit granting whose current credit limit is less than a preset threshold is less than a preset threshold, then the credit granting operation is performed.

[0013] In a second aspect, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the authorization processing method described in any of the preceding claims.

[0014] In addition, the present invention also provides a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the trust processing method described in any of the above claims.

[0015] In this invention, considering that customer data pushed by the quantitative big data platform may have quality issues such as format errors, missing fields, and parsing failures, directly executing batch processing tasks based on defective customer data would lead to widespread errors in the admission results and credit limits of a large number of customers. To avoid widespread errors in the admission results and credit limits of a large number of customers, which could trigger more serious production accidents, a synchronization table is added as a buffer before writing customer data to the business table. The customer data in the synchronization table is then subjected to integrity checks, format validity checks, and distribution consistency checks sequentially. Data is only synchronized to the business table after all checks pass. Validating the data in the synchronization table can block defective data from entering the risk control decision-making process at the data source, ensuring that the customer data used for subsequent admission and credit granting is of high quality and high reliability, thereby reducing the risk of widespread credit granting errors due to data quality issues.

[0016] In addition, considering that although the data synchronized to the business table has passed basic quality checks, there may still be anomalies that are difficult to capture through static rules, such as sudden changes in data distribution, rule configuration deviations, or implicit errors in business logic, a pre-approval decision rule verification step is added before the formal credit granting operation. This involves using pre-approval decision rules to perform a preliminary pre-approval judgment on the customer data in the business table. Only if the pre-approval result is satisfactory will the credit granting operation proceed. This pre-approval process uses the exact same decision logic as the formal approval process, but the results are not publicly available. Essentially, it's a trial run of the customer data and decision rules, effectively identifying batch approval result deviations caused by abnormal data distribution or rule configuration errors. This prevents erroneous decisions from directly affecting real customers, building a security barrier before the decision results take effect, and further improving the fault tolerance of the risk control process and business security.

[0017] These features and advantages of the present invention will be disclosed in detail in the following specific embodiments and accompanying drawings. The preferred embodiments or means of the present invention will be shown in detail in conjunction with the accompanying drawings, but are not intended to limit the technical solutions of the present invention. In addition, each of these features, elements and components appearing in the following text and drawings is a plurality of, and different symbols or numbers are used for convenience of representation, but all represent parts with the same or similar construction or function. Attached Figure Description

[0018] The present invention will be further described below with reference to the accompanying drawings: Figure 1 A flowchart illustrating one embodiment of the credit granting processing method provided by the present invention; Figure 2 This document presents a flowchart illustrating the process of performing integrity checks, format validity checks, and distribution consistency checks on customer data to determine the customer data verification results. Figure 3 This is a schematic diagram illustrating the switching between the synchronization table and the business table provided by this invention. Figure 4 This is a schematic diagram of the process for pre-access verification of customer data using pre-access decision rules provided by the present invention; Figure 5 This is a schematic diagram of the process for pre-admission judgment of customers to be granted credit based on customer data, provided by the present invention. Figure 6 This is a schematic diagram of the process for extracting business feature values ​​corresponding to each pre-admission decision rule from a business table using pre-admission rule identifiers, as provided by the present invention. Figure 7 This is a schematic diagram of the feature code and data source code (business data encoding) provided by the present invention; Figure 8A schematic diagram of the Groovy script representing the average customer revenue over the past three months provided by this invention. Figure 9 This is a schematic diagram of the process for collecting service feature values ​​provided by the present invention; Figure 10 This is a schematic diagram illustrating the extraction of the corresponding list configuration identifier from the list configuration repository provided by the present invention; Figure 11 A schematic diagram illustrating the list configuration repository provided by this invention; Figure 12 This is a schematic diagram of the credit granting process based on pre-admission results provided by the present invention; Figure 13 This is a flowchart of the authorization operation provided by the present invention. Detailed Implementation

[0019] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described are intended to explain the present invention and should not be construed as limiting the invention.

[0020] The terms "an embodiment," "example," or "trademark" used in this specification refer to a particular feature, structure, or characteristic described in connection with the embodiment itself that may be included in at least one embodiment disclosed in this invention. The phrase "in an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0021] As a first aspect of the present invention, a credit granting processing method is provided, such as Figure 1 As shown, the method includes: In step S110, customer data of customers to be granted credit is obtained and stored in a synchronization table.

[0022] In this embodiment, customer data can include customer operational indicator data, customer and related party risk data, and loan-related operational risk control data. Customer operational indicator data can be used to assess the repayment ability and operational stability of prospective borrowers, and is particularly suitable for business loans (corporate lending) or operating loans to individual businesses. Customer operational indicator data may include data such as the customer's average monthly revenue / income, operating income, gross profit margin, net profit, compound annual growth rate of revenue in recent years, asset-liability ratio, current ratio, operational capacity / efficiency, and cash flow status.

[0023] Customer and related party risk data is a crucial source of information for assessing customer creditworthiness and potential risks. This data can be broadly categorized into internal and external data. Internal data primarily originates from the financial institution's own business systems and historical records, while external data comes from credit reporting agencies, third-party data service providers, and other channels. Internal data mainly includes the historical credit records of potential borrowers within the institution, such as the number of overdue payments, the number of overdue days, and credit utilization rates; repayment behavior characteristics, such as whether they prepay or frequently apply for credit limit increases; and historical records of credit limit changes, such as credit limit applications, adjustments, and cancellations. External data primarily includes public risk information, anti-fraud and blacklist data, and related network data, such as shareholders, actual controllers, senior executives, guarantors, and co-borrowers.

[0024] Mid- and post-loan operational risk control data are crucial support data for financial institutions to continuously monitor customer status and manage risk exposure after loan disbursement. Covering the entire process from loan disbursement to final repayment, it is of key value for early identification of risk signals and the development of differentiated post-loan strategies. Mid- and post-loan operational risk control data includes repayment behavior data, post-loan inspection data, risk warning data, and collection and non-performing loan disposal data. Repayment behavior data includes partial repayments, loan extensions, and refinancing; post-loan inspection data consists of regular or irregular checks conducted by account managers or risk managers on borrowers; and risk warning data includes risk signals automatically triggered by various monitoring systems.

[0025] Specifically, electronic devices running risk control systems can receive customer data from potential credit customers from a quantitative big data platform and store the received customer data in a pre-created synchronization table. This synchronization table has the same table structure as the business table, but the two are physically isolated from each other.

[0026] In step S120, the customer data in the synchronization table is subjected to integrity verification, format validity verification, and distribution consistency verification to obtain the customer data verification result.

[0027] In this embodiment, integrity verification ensures that customer data is not missing, such as a reasonable number of rows and non-empty key fields, preventing incomplete pre-admission decisions due to insufficient data. Format validity verification ensures that data content conforms to predetermined specifications, such as positive amounts, unique identifiers, and decryptable encrypted data, preventing parsing failures or logical inconsistencies due to incorrect data formats. Distribution consistency verification ensures that the statistical characteristics of numerical indicators are within normal fluctuation ranges, such as no abnormal drift in mean and extreme values, preventing batch misjudgments caused by sudden changes in data distribution.

[0028] It's worth noting that in related technologies, big data platforms directly push customer data to business tables used by the business. After the push is complete, they directly perform formal batch processing tasks based on the customer data in the business tables, i.e., executing access and credit granting operations. Furthermore, risk control decisions such as access and credit granting have a strict multi-dimensional dependence on data quality. Verification of a single dimension may not fully guarantee data reliability. Once the pushed customer data has quality issues, it will directly and significantly impact the access and credit granting results for customers awaiting credit, leading to production accidents. Therefore, to avoid production accidents caused by customer data quality, customer data must undergo joint verification across multiple independent dimensions before formal batch processing. Only when all three dimensions pass verification can the customer data be proven to meet the reliability requirements of risk control decisions in terms of completeness, compliance, and consistency. Failure of any verification indicates a potential defect in the data. Forcing it into the subsequent access and credit granting process will likely lead to widespread access or credit granting errors. Therefore, to ensure that customer data meets the reliability requirements of risk control decisions in terms of completeness, compliance, and consistency, further, as an optional implementation method, refer to... Figure 2 As shown, Figure 2 A flowchart illustrating the process of verifying customer data integrity, format validity, and distribution consistency, and determining the verification results, is provided. Step S120 specifically includes: In step S210, the customer data in the synchronization table is subjected to integrity verification, format validity verification, and distribution consistency verification to obtain integrity verification results, format validity verification results, and distribution consistency verification results.

[0029] In step S220, if the integrity verification result, the format validity verification result, and the distribution consistency verification result are all passed, the customer data verification result is determined to be passed.

[0030] Specifically, integrity verification can be performed from two dimensions: the number of data rows in the synchronized table and the null value rate. The integrity verification result is considered successful if the difference between the number of data rows in the synchronized table and the average number of rows within a preset time period does not exceed a preset difference, and the null value rate of customer identifiers in the synchronized table is not greater than a preset null value rate. Conversely, the integrity verification result is considered unsuccessful if the difference between the number of data rows in the synchronized table and the average number of rows within a preset time period exceeds a preset difference, or if the null value rate of customer identifiers in the synchronized table is greater than a preset null value rate. This is because drastic fluctuations in the number of rows, such as sudden increases, decreases, or zero, often indicate abnormal ETL (Extract, Transform, Load) task execution, such as data source interruption, incorrect filtering conditions, or partial partition loss. Running batch processing directly based on such customer data would lead to a large number of customers being incorrectly admitted or rejected. The customer identifier is a core field associated with all risk control indicators; if the null value rate is too high, a large amount of customer data will not be correctly identified, thus preventing admission judgments or credit calculations. Therefore, by using both row count fluctuations and null value rates for verification, it is possible to effectively identify and block data with abnormal volume or integrity from entering the risk control decision-making process for admission and credit granting.

[0031] When performing format validity checks, verification can be conducted from two dimensions: the total transaction amount and the customer identifier in the synchronization table. Specifically, if the total transaction amount of all customers awaiting credit in the synchronization table is not less than a preset amount, and the transaction identifier information in the synchronization table is unique, the format validity check is passed. If the total transaction amount of all customers awaiting credit in the synchronization table is not greater than the preset amount, or if the transaction identifier information in the synchronization table is duplicated, the format validity check is deemed failed. This is because a low total transaction amount, such as being far below the business norm or historical low, may stem from errors in parsing the amount field, such as unit confusion, decimal point misalignment, or data aggregation logic errors. Without verification, this will directly lead to serious deviations in credit limit calculation. Transaction identifier information such as order numbers and transaction serial numbers must be unique at the primary key level. Duplicate records will cause duplicate counts in subsequent transaction count and amount aggregation statistics, resulting in distorted risk control indicators. Therefore, by checking the reasonableness threshold of the amount and the uniqueness of the transaction identifier, data quality issues that clearly violate basic business logic can be filtered out.

[0032] When performing distribution consistency verification, it can be performed on all numerical customer data dimensions in the synchronized table. That is, if all data indicators for numerical customer data in the synchronized table are within their corresponding preset ranges, the distribution consistency verification result is passed. Conversely, if any data indicator for numerical customer data in the synchronized table is outside its preset range, the distribution consistency verification result is determined to be failed. This is because even if row count, null values, and format verification all pass, data distribution drift may still occur. For example, due to upstream model updates or data source changes, the overall distribution of numerical data may deviate from its historical normal range, such as a uniform 10-fold increase in the average monthly revenue for all customers. Such anomalies are difficult to identify through individual records, but by statistically analyzing the value ranges of each numerical indicator under normal conditions, the overall distribution mutation can be captured. Without verification, data distribution drift will lead to a systematic overestimation or underestimation of credit results for a large number of customers, triggering large-scale business risks.

[0033] After obtaining the integrity verification result, format validity verification result, and distribution consistency verification result, if all three results pass, the customer data verification result is determined to be passed; conversely, if any one of these results fails, the customer data verification result is determined to be failed.

[0034] In addition, since the customer data pushed by the big data platform includes customer characteristic indicators, customer information, customer classification, and other data calculated by the model, two typical verification rules and their reasons can be set for specific data pushed by the big data platform. For example, if there is a risk label field in the customer characteristic indicators, and this field is stored in unstructured JSON format, the verification rule for this case is to check whether the extracted risk label value belongs to a predefined set of valid enumerations, such as only being high-risk, medium-risk, or low-risk. If any record in the synchronization table has a risk label value that is not within the corresponding enumeration range, the verification is deemed to have failed, the batch processing is terminated, and an alarm is sent to the quantitative personnel. This is because the big data platform has weak error handling capabilities for JSON format fields. When a field is missing or of the wrong type, it will only return an empty value, but it cannot distinguish whether this empty value is due to the absence of data to begin with or due to parsing failure, making it difficult for subsequent access and credit verification logic to accurately determine the cause.

[0035] When the ID number field of customer data in the synchronization table is stored in encrypted form, the verification rule is to first decrypt the encrypted field to obtain the plaintext ID number, and then use regular expressions and other rules to verify whether its format is correct. If any non-empty encrypted data is decrypted and the format is incorrect, the verification is deemed to have failed, the batch processing is terminated, and an alarm is sent to the quantitative personnel.

[0036] To facilitate a better understanding of this embodiment, a specific example is provided below: Assuming the application scenario is an e-commerce data warehouse, the synchronized table `dwd_order_detail` stores daily order details. Assume the preset difference between the number of rows in the synchronized table and the average number of rows within a preset time period is 20, the preset amount is 1 million, the allowed number of duplicate transaction identifiers is 0, and the preset null value rate is 1%. For each numerical customer data point, its average value during historical normal operation can be calculated, and the allowed fluctuation upper limit is set to 105% of the average value, and the lower limit is set to 95% of the average value. The range formed by 95% and 105% of the average value is used as the preset range for each numerical customer data point.

[0037] When validating the synchronization table, the difference between the daily order row count and the average row count over a preset time period can be calculated. If the difference does not exceed 20, the row count verification is considered successful. Alternatively, after obtaining the row count difference, the ratio of the difference to the preset average row count can be used as the row count fluctuation ratio. If the fluctuation ratio is not greater than the preset fluctuation ratio, the row count verification is considered successful. For order transactions in the synchronization table, it is determined whether the customer identifier for each order transaction is missing, and the number of order transactions with missing customer identifiers is counted. The ratio of the number of order transactions with missing customer identifiers to the total number of all order transactions is used as the customer identifier null value rate. If the null value rate is not greater than 1%, the null value rate verification is considered successful, and the integrity verification result is further confirmed as successful.

[0038] Then, the total transaction amount in the synchronization table is calculated, which is the sum of the transaction amounts of all customers awaiting credit. If the total transaction amount is not less than 1 million, the amount verification is passed. For each transaction order in the synchronization table, a duplicate check is performed based on the transaction identifier of each transaction order. If there is no duplicate transaction identifier, the transaction identifier verification is passed. In this case, the format validity check result is determined to be passed.

[0039] Finally, for numerical customer data, specifically in e-commerce data warehouse scenarios, this data can be configured as order statuses for transaction orders, such as pending payment, paid, completed, and canceled. During distributed consistency verification, custom SQL can be written to group and statistically analyze all transaction order data for the day, calculating the number of records for each order status and its percentage of the total number of orders that day. For example, the percentage for pending payment could be 18%, paid 62%, completed 14%, and canceled 6%. Then, the percentages of each order status for the day are compared to corresponding preset ranges. If the percentages of all order statuses are within the preset range, the distributed consistency verification passes; if the percentage of any status fluctuates beyond the preset range, the distributed consistency verification fails.

[0040] In this embodiment, row count fluctuation and null value rate verification can effectively identify batch data loss caused by ETL task execution anomalies or data transmission loss, avoiding deviations in access and credit granting decisions due to a sudden decrease in the number of data rows or a large number of empty key fields. Transaction total amount and transaction identifier uniqueness verification can filter out problems that clearly violate basic business logic, such as incorrect amount units, abnormal numerical parsing, or duplicate primary keys, preventing the overall statistical results from being polluted by a single or small number of erroneous data. Numerical indicator distribution consistency verification can capture overall distribution drift caused by upstream model changes or data source switching, preventing large-scale risks of systematically high or low credit limits. Finally, the logic of only considering data qualified if all three verification results pass ensures that data defects in any dimension can be blocked in a timely manner, thereby guaranteeing high reliability and consistency of the data on which risk control decisions are based from the source, significantly reducing the probability of production accidents caused by data quality issues, and improving the robustness and business security of credit risk control operations.

[0041] In step S130, if the customer data verification result is successful, the customer data in the synchronization table is synchronized to the business table.

[0042] If the customer data verification result passes, the customer data in the synchronization table can be synchronized to the business table. However, when synchronizing customer data from the synchronization table to the business table, it's important to consider the risks. If the customer data directly overwrites the business table after routine data checks, there are risks such as partial writes to the business table during the data update process, inconsistent query results, and the inability to quickly revert to the previous stable version. Therefore, to avoid these risks, an atomic renaming operation can be used to synchronize customer data from the synchronization table to the business table, i.e., refer to... Figure 3 As shown, Figure 3 This is a diagram illustrating the switching between the synchronization table and the business table.

[0043] Specifically, after completing the ETL processing of customer operating indicators, risk tags, and other data, the quantitative big data platform (DataWorks) pushes the data to the risk control system. The risk control system can then store the received customer data in pre-created synchronization tables, such as risk_aaa_sync, risk_bbb_sync, risk_ccc_sync, and risk_xxx_sync. If the customer data verification result is successful, the currently used business table can be renamed to a temporary backup table to retain the old version of the data for possible rollback in the future. For example, if the currently used business table is risk_aaa and the synchronization table that needs to be synchronized is risk_aaa_sync, it can be renamed to the temporary backup table risk_aaa_tmp, i.e., risk_aaa rename to risk_aaa_tmp. Then, the synchronization table risk_aaa_sync is renamed to the business table risk_aaa, that is, risk_aaa_syncrename to risk_aaa. Finally, the aforementioned temporary backup table risk_aaa_tmp is renamed to the synchronization table risk_aaa_sync, that is, risk_aaa_tmp rename to risk_aaa_sync, thus completing the switch between the synchronization table and the business table.

[0044] In this embodiment, atomic table switching operations are employed, ensuring consistency and immediacy in the business table update process. During the switch, the risk control service only needs to wait briefly or remain completely unaware, guaranteeing the continuity of risk control decision-making. Furthermore, by retaining the original business table as a backup copy during the table switch, if data anomalies are detected after the switch, a renaming operation can be performed in reverse to quickly revert to the previous stable version, significantly improving the system's fault tolerance and emergency response efficiency. Simultaneously, this mechanism physically isolates the data reception and data usage stages, allowing the quantitative platform and electronic devices running the risk control system to evolve and optimize independently, reducing the coupling between modules and improving the system's maintainability and scalability.

[0045] In step S140, the customer data in the business table is verified using the pre-admission decision rules to obtain the pre-admission result of the customer to be granted credit.

[0046] In this embodiment, the pre-approval process can be implemented during the credit application stage. Based on the customer data of the customer to be granted credit and preset pre-approval decision rules, it can be determined whether the customer meets the pre-approval threshold for the credit product. The pre-approval result is usually either "pass" or "fail". Pre-approval can be performed before formal approval. Using the same logic and rules, the customer data of the customer to be granted credit is simulated and calculated. The simulation result is then compared with the currently effective formal approval result. This does not change the formal approval result; it is only used to verify the quality of customer data and whether the rule logic is consistent with expectations, preventing large-scale misjudgments due to data anomalies or logical errors.

[0047] Understandably, different credit products have different pre-approval decision rules. For example, AP products require prospective credit customers to be between 22 and 60 years old, BP products require them to be between 18 and 65 years old with an average monthly income of no less than 5,000 yuan, and CP products may additionally require them to have no history of overdue payments. In traditional implementations, the pre-approval decision rules for each credit product are often hard-coded into the decision logic of the risk control system. When launching a new credit product or adjusting the admission conditions of an existing one, developers need to modify the code, recompile, test, and go through the entire deployment process, resulting in long deployment cycles, slow response times, and an inability to meet rapidly changing market demands. Furthermore, because the rule logic of each product is scattered throughout the code, rule reusability is poor, maintenance costs are high, and new defects are easily introduced due to code modifications.

[0048] Therefore, to decouple the credit product from the pre-admission decision rule logic, and to achieve the configurability, dynamism, and standardization of the pre-admission decision rules, further, as an optional implementation method, refer to... Figure 4 As shown, Figure 4 This is a flowchart illustrating the process of pre-access verification of customer data using pre-access decision rules. Step S140 specifically includes: In step S410, a pre-admission rule identifier corresponding to the credit product of the customer to be granted credit is determined.

[0049] In step S420, a pre-admission decision rule corresponding to the pre-admission rule identifier is determined.

[0050] In step S430, the business feature values ​​corresponding to each of the pre-admission decision rules are extracted from the business table using the pre-admission rule identifier.

[0051] In step S440, the feature placeholders in the expression of the pre-admission decision rule are replaced with the corresponding business feature values ​​to obtain the pre-admission decision rule expression.

[0052] In step S450, a decision judgment is made for each of the pre-admission decision rule expressions to obtain the decision result corresponding to each of the pre-admission decision rule expressions.

[0053] In step S460, if all the decision results are passed, the pre-admission result of the customer to be granted credit is determined to be passed.

[0054] In this embodiment, the pre-admission rule identifier can be the code of the pre-admission decision scenario, which is usually bound to a specific credit product and used to associate a set of pre-admission decision rules.

[0055] Specifically, refer to Figure 5 As shown, Figure 5 This is a flowchart illustrating the pre-approval process for customers seeking credit based on customer data. After synchronizing the customer data of potential credit customers to the business table and clearing the data in the pre-approval related tables, such as the pre-approval result table, ensures that the simulation results are not influenced by historical data. Subsequently, based on the customer data in the business table, customers are grouped according to the credit products applied for by the potential credit customers. The customer data corresponding to each group of credit products is then read in batches using a sharding and pagination approach to avoid loading too much data at once and causing memory pressure.

[0056] For the customer data of the customer awaiting credit approval, the system can determine the process nodes under the corresponding decision process based on the credit product applied for by the customer, such as the process code (process_code) and process name (process_name). This involves constructing multiple decision process nodes (node_code) according to different customer data types, and then passing the pre-admission rule identifier (rule_code) from each decision-related node to the decision engine according to their node hierarchy (node_index). The decision engine then retrieves the corresponding pre-admission decision rule (rule_condition) from the deployed rule base based on the received pre-admission rule identifier. Each pre-admission decision rule can include a rule code, a rule condition expression, feature placeholders, and a rule policy after a successful match (rule_policy). The rule condition expression can be represented as follows: [userAge]<22||[userAge]>60, where userAge is a feature placeholder.

[0057] It is worth mentioning that when extracting business feature values ​​corresponding to each pre-admission decision rule from the business table using pre-admission rule identifiers, it's important to consider that in traditional risk control systems, the calculation logic of business feature values ​​is usually tightly coupled with the specific data source query code. When the calculation method of business feature values ​​needs to be adjusted, the business code must be modified and the service restarted, leading to business response delays. Furthermore, the repeated data retrieval and calculation of the same business feature indicator for different decision scenarios also causes resource waste and maintenance difficulties. Therefore, to decouple data source acquisition from business feature value calculation logic and improve data extraction efficiency, as an optional implementation method, we can refer to... Figure 6 As shown, Figure 6 This is a flowchart illustrating the process of extracting business feature values ​​corresponding to each pre-admission decision rule from the business table using pre-admission rule identifiers. Step S430 specifically includes: In step S610, the service data code corresponding to the pre-admission rule identifier and the feature code corresponding to the service data code are determined.

[0058] In step S620, the corresponding business data is read from the corresponding business table using the customer identifier of the customer to be granted credit and the business data code.

[0059] In step S630, the Groovy script corresponding to the feature code is invoked to convert the corresponding business data into business feature values.

[0060] In this embodiment, the business table corresponds to the business data type, the business data type corresponds one-to-one with the business data code, the business data code corresponds to multiple feature codes, and the feature codes correspond one-to-one with Groovy scripts. The Groovy scripts are used to convert the business data corresponding to the feature codes into business feature values, as detailed below. Figure 7 and Figure 8 As shown, Figure 7 This is a schematic diagram of the feature code and the data source code (business data encoding). Figure 8 This is a code diagram of the Groovy script representing the average revenue received by a client over the past three months.

[0061] Here, business data encoding can be an abstract encoding used to identify the data type of the business. Feature codes can be logical names used for risk control indicators, as shown in the reference section. Figure 7 As shown, Figure 7This includes the correspondence between feature codes and business data source codes, as well as the meaning of each feature code's annotations. For example, `clientInboundAvg3M` represents the customer's average inflow over the past three months, and `inboundDeviationV2` represents the inflow deviation V2, which is a risk control feature indicator used to measure the degree of fluctuation of the customer's actual inflow amount relative to its historical expected level. V2 indicates the second version of this feature, which may be an optimization of the initial version in terms of data source, calculation method, or model algorithm. Feature codes can be used as placeholders in rule condition expressions. The Groovy script encapsulates the specific logic for calculating feature values ​​from raw business data, such as receiving the customer's date of birth and calculating their age in years based on the current date.

[0062] exist Figure 8 In this code, the feature script itself is a piece of Groovy code, and the logic of this code can be modified and applied online. For example... Figure 8 The feature script logic ultimately determines the feature value: if the customer's average revenue over the past three months is greater than or equal to 10,000, then the feature value is Y; otherwise, the feature value is N. If you need to change the feature value from 10,000 to 8,000, you can manually modify it in the page management interface for it to take effect immediately.

[0063] Specifically, after determining the pre-admission rule identifier, the business data code corresponding to the pre-admission rule identifier and the feature code associated with each business data code can be retrieved from the rule configuration library. This means retrieving the data source and feature code required for the current decision-making scenario; the decision process scenario code can be xxx_prcess_code. The rule configuration database maintains the business relationship between rule identifiers and business data codes, as well as the feature codes attached to each business data code.

[0064] After obtaining the business characteristic code, the data center's data query interface can be invoked in conjunction with the customer identifier of the customer to be granted credit. The data center generates a data query statement based on the physical configuration of each business code, including database connection information, table names, query fields, and conditional query templates. Subsequently, based on the generated data query statement, the data center reads the business data corresponding to the customer to be granted credit from the corresponding business table, and temporarily stores the read business data in a structured format, i.e., queries the data center, and assembles the query data parameters.

[0065] Specifically, as an optional implementation, when calling the data center's data query interface to read business data, the data center can adopt a concurrent execution architecture, using a unified interface to make parallel calls to multiple data sources to improve the efficiency of acquiring feature indicators. Specifically, refer to... Figure 9 As shown, Figure 9The flowchart illustrates the process of collecting business feature values. The data center is configured with multiple data source access ports, including data source 1 to data source n. The data sources cover heterogeneous data sources such as internal business database tables, external credit scoring interfaces, and list configuration repositories. When a feature query request for any credit product is received, the data center does not access the data sources sequentially one by one, but adopts a concurrent execution mechanism to initiate data collection tasks to multiple data sources simultaneously.

[0066] Upon receiving the collection command, each data source returns raw data to the data center in parallel. Subsequently, the data center, based on a pre-configured feature script (i.e., a Groovy script), converts the raw data returned by each data source into standardized feature indicators, generating Feature 1, Feature 2, and so on up to Feature n. Feature indicators are business characteristic values, which can be quantitative values ​​or status identifiers extracted or calculated from the raw data and used for risk control decisions, such as customer age, average revenue over the past three months, and blacklist hit indicators.

[0067] After calculating all feature indicators, the data center assembles features 1 to n into a complete feature indicator result set and returns it to the credit granting product that initiated the query in a unified key-value pair structure. This feature indicator result set can be referenced by any credit granting product as needed in admission judgment or credit granting calculation, realizing the sharing and reuse of feature indicators across multiple products and scenarios.

[0068] It's important to note that while customer age and transaction history can be extracted from the business table when retrieving business data, information like blacklists and whitelists is updated in real-time, whereas customer age and transaction history are updated in batches daily. Therefore, storing blacklists and whitelists in the business table necessitates a full data refresh of the business table whenever the lists change, impacting its stability. Furthermore, as the number of list types increases, it leads to a bloated business table structure, such as requiring separate columns for each list type, thus reducing query efficiency.

[0069] Therefore, to avoid the problems of table structure proliferation, duplicate operation interfaces, and high maintenance costs caused by directly storing data such as blacklists and whitelists in business tables, when reading corresponding business data from the corresponding business table using the customer identifier and business data code of the customer to be granted credit, if the business data type is blacklist, whitelist, or graylist configuration data, the corresponding list configuration information can be extracted through the data warehouse interface. That is, when the business data type corresponding to the business data code is list configuration data, the data warehouse interface is called to extract the corresponding list configuration identifier from the list configuration warehouse based on the customer identifier; wherein, the list configuration warehouse is a mapping table composed of the customer identifier and the list configuration identifier.

[0070] Specifically, refer to Figure 10 As shown, Figure 10 This diagram illustrates the extraction of the corresponding list configuration identifier from the list configuration repository. When the business data type is determined to be list configuration data, a unified API at the service layer, namely the data warehouse interface, can be invoked. The data warehouse interface receives a request containing a business data code and the customer identifier of the customer to be granted credit. After identifying the request as belonging to the list configuration data type based on the business data code, the data warehouse interface routes it to the underlying list configuration repository and extracts the corresponding list configuration identifier (List_type) from the list configuration repository based on the customer identifier information (userId), such as a blacklist (BLACK) or a whitelist (WHITE). The whitelist can be a list of customers deemed low-risk and with excellent credit by financial institutions. Customers on this list can enjoy faster and simpler services when applying for actual use, i.e., drawing up a loan limit. The list configuration repository is a mapping table between customer identifiers and list configuration identifiers.

[0071] Alternatively, as another optional implementation, the list configuration repository can adopt a metadata-driven multi-dimensional matching architecture, storing various list data through a unified mapping table. Specifically, this mapping table may include a business type field (biz_type) to identify the business scenario to which the list belongs; a list configuration identifier (list_type) to distinguish whether the record is a metadata definition (META) or a specific policy list, such as WHITE or BLACK; and one or more dimension fields, such as dimension1 and dimension2, to define the matching conditions for the list. (See reference...) Figure 11 As shown, Figure 11This diagram illustrates the list configuration repository for a business scenario involving loan disbursement. When the list description (list_desc, listdescription) for a business scenario is a loan disbursement list (loan_expend_name_list), the corresponding list configuration repository is first located based on the preset business data code. In the repository, records with list_type as META serve as the metadata definition for this business scenario. Their dimension fields, dimension1=userId and dimension2=product (credit product), specify the matching dimensions used in subsequent specific list data. Based on the metadata definition, the customer identification information (123) to be matched and auxiliary matching values ​​(such as the identifier of the credit product (product) (LY-CP)) are precisely matched with the corresponding dimensions in the list data records. If the match is successful, the list_type field value in the record is extracted as the list configuration identifier, such as WHITE for whitelist and BLACK for blacklist, to indicate the list category to which the customer belongs in the business scenario. If the match fails, a no-match result is returned to indicate that the customer does not belong to any preset list category. In this example, test2, test3, and test4 can be test placeholders in the list description field, used to explain the purpose or remarks of the list record. The use of test2, test3, and test4 in the example is only to demonstrate the data structure of the list configuration warehouse, that is, multiple list types can be stored at the same time under the same business type, such as whitelist and blacklist. Each list type supports multi-dimensional matching, such as userId and product, and each record can be appended with descriptive information for subsequent maintenance and traceability.

[0072] Finally, based on each feature code, the corresponding Groovy script is loaded from the feature script library. After loading the corresponding Groovy script, the corresponding business data can be passed as input parameters to the Groovy script, and the script is executed by the Groovy script engine. The result returned after the script execution is the business feature value of that feature code, such as age 30.

[0073] In this embodiment, a four-level mapping mechanism is established, consisting of pre-admission rule identifiers, business data codes, feature codes, and Groovy scripts. This completely decouples the physical storage of business data from the logical calculation of business feature values. Specifically, the business data code completely isolates the underlying physical data storage from the upper-layer business logic. When database migrations, table structure changes, or other data source replacements are required, only the configuration mapping of the business data code needs to be modified, without altering any pre-admission decision rules or application code. This significantly reduces maintenance costs and improves scalability. Secondly, the feature codes and Groovy scripts are one-to-one, and the scripts support dynamic loading and hot updates. When risk control strategies are adjusted, such as modifying age calculation rules or adjusting credit indicator thresholds, business personnel can directly edit the scripts in the management backend and generate updates instantly. First, it reduces policy response time from days to minutes without requiring service restarts or cumbersome deployment processes, especially meeting the need for rapid response in emergency situations. Second, by concurrently reading business tables through customer identifiers and business data encoding, and combining this with Groovy scripts to batch convert feature values, it avoids the performance bottleneck of traditional rule-by-rule database queries, significantly reducing I / O overhead and improving decision-making capabilities in high-concurrency scenarios. Finally, this design achieves complete decoupling of decision rules and data models, meaning rule writers only need to focus on feature codes without worrying about data sources and calculation details. The same feature code can be reused in multiple decision scenarios, ensuring the consistency of feature value calculation logic, thereby comprehensively improving the flexibility, reliability, maintainability, and development efficiency of the credit risk control system.

[0074] After extracting the business feature values ​​corresponding to each pre-admission decision rule through steps S510 to S530, the feature placeholders in the expression of the pre-admission decision rule can be replaced with the corresponding business feature values ​​to generate an executable pre-admission decision rule expression. For example, if the expression of the pre-admission decision rule is [userAge]<22||[userAge]>60, and the corresponding business feature value is 30, the pre-admission decision rule expression can be obtained as 30<22||30>60, which assembles the execution decision input parameters.

[0075] After obtaining the pre-admission decision rule expressions, each expression can be evaluated sequentially. For example, 30<22||30>60 results in false. Based on the evaluation result, it is determined whether the pre-admission decision rule is met. If the pre-admission decision rule expression is true, the rule is met, and the decision result of the current rule is determined to be disqualified according to the strategy of the pre-admission decision rule. If the pre-admission decision rule expression is false, the rule is not met, and the decision result of the current rule is determined to be qualified according to the strategy of the pre-admission decision rule, i.e., the decision engine is invoked to execute the decision.

[0076] After obtaining the decision results of all pre-admission decision rule expressions, if all the decision results of the pre-admission decision rule expressions are passed, the pre-admission result of the customer to be granted credit is determined to be passed. If the decision result of any pre-admission decision rule expression is failed, the pre-admission result of the customer to be granted credit is determined to be failed, and an alarm is triggered to notify manual intervention for data investigation.

[0077] In this embodiment, a pre-admission simulation stage, identical to the formal admission logic, is added before the formal batch processing. This allows any batch decision deviations caused by defects in quantitative data quality, incorrect rule configuration, or abnormal feature scripts to be detected and blocked before affecting real customers, thus eliminating the risk of production accidents caused by large-scale admission errors from a process perspective. By decoupling the pre-admission rule identifier from the specific rule content, independent configuration and dynamic loading of rules are achieved. Risk control personnel can adjust the admission logic (such as modifying the age threshold) without modifying the code, significantly improving the iteration efficiency and flexibility of risk control strategies. Furthermore, by using a unified data center to concurrently extract feature values ​​from verified business tables and dynamically calculate them using Groovy scripts, it is ensured that the data on which the pre-admission judgment depends is completely consistent with the formal decision, and the feature calculation logic can be hot-updated, further shortening the response time for business changes. Finally, by adopting a strict logic that pre-admission is only approved when all rules pass, and a statistical comparison mechanism between pre-admission results and formal results, such as pass rate fluctuation threshold alarms, a reliable security barrier is constructed, significantly improving the robustness and business continuity of the credit risk control system.

[0078] In addition, by centrally storing the mapping relationship between customer identifiers and list configuration identifiers in a separate list configuration repository, unified management of all types of lists, such as whitelists, blacklists, graylists, and institutional lists, is achieved. Adding a new list type only requires adding a mapping record without creating a database table or writing new code, fundamentally eliminating the problems of table structure proliferation and redundant development, and significantly reducing system maintenance costs. Secondly, the unified API design at the service layer allows upper-layer risk control applications to call the list query interface without discrimination, without needing to concern themselves with the underlying storage details. This achieves standardization and reusability of list access logic, significantly improving system scalability and development efficiency. Thirdly, the list configuration repository is independent of the batch business data synchronization process, supporting real-time CRUD operations on lists by operations personnel. Changes take effect immediately without restarting the service or rerunning batches, thereby reducing the response time of risk control strategies from hours to seconds. Finally, direct mapping queries based on customer identifiers avoid the overhead of traditional multi-table joins or fuzzy matching. Combined with dedicated indexes, this significantly improves the performance of list hit judgment in high-concurrency scenarios, ensuring the real-time nature and stability of risk control decisions.

[0079] In step S150, if the pre-admission result of the customer to be granted credit is approved, the credit granting operation is performed on the customer to be granted credit.

[0080] It is worth noting that the pre-approval results need to be verified before formal access or credit granting. If the pre-approval results are not compared and verified with the formal results and are directly used for formal access or credit granting, and if the data on which the pre-approval is based has distribution drift or rule configuration errors, it will lead to a significant anomaly in the formal access pass rate, thereby causing widespread customer credit granting errors. Therefore, to avoid subsequent credit granting errors, as an optional implementation method, refer to... Figure 12 As shown, Figure 12 This is a schematic diagram of the credit granting process based on pre-admission results. Step S150 specifically includes: In step S1210, the pre-admission results of each customer to be granted credit are stored in the pre-admission result table.

[0081] In step S1220, the first percentage of pre-admission results in the pre-admission result table is determined to be the first percentage of those who have passed.

[0082] In step S1230, the admission result in the currently effective formal admission result table is determined to be the second percentage of those who have passed.

[0083] In step S1240, if the difference between the first percentage and the second percentage is less than a preset threshold, an admission operation is performed on the customers whose pre-admission result is passed, and the formal admission result table is updated using the pre-admission result table.

[0084] In step S1250, a credit granting operation is performed on the credit-seeking customers who have passed the credit granting process in the updated official access result table.

[0085] Specifically, after obtaining the pre-approval results for each customer awaiting credit, these results can be stored in a pre-approval result table. The ratio of the number of customers with approved pre-approval results in the pre-approval result table to the total number of customers awaiting credit is used as the first percentage. Then, the currently effective formal approval result table is queried, and the ratio of the number of customers with approved formal approval results in the formal approval result table to the total number of customers awaiting credit is used as the second percentage.

[0086] The difference between the first and second percentages, i.e., the absolute value of the difference, is then calculated and compared with a preset threshold. If the difference is less than the preset threshold, it indicates that the pass rate of the pre-admission result is basically consistent with the current formal admission result, the data quality and logic meet the expected rules, and the admission operation is performed on the pending credit customers whose pre-admission result is passed. At the same time, the data in the formal admission result table is updated using the data in the pre-admission result table. Finally, credit operations are performed on each customer who has passed the admission in the updated formal admission result table. Conversely, if the difference is greater than the preset threshold, subsequent admission and credit operations are stopped, and an alarm is triggered to notify manual intervention for data investigation.

[0087] In this embodiment, by comparing the pass rates of the pre-admission results and the formal admission results, abnormal fluctuations in data or rules can be effectively identified. This is because the pre-admission results are simulated based on the latest pushed customer data and the latest configured pre-admission decision rules, while the formal admission results are the currently effective stable benchmark. If the difference in the pass rates is within a preset threshold, it indicates that the new customer data quality is qualified and the changes to the pre-admission decision rules are in line with expectations, and formal admission can be safely executed. If the difference exceeds the threshold, it indicates that there may be missing data, sudden changes in distribution, or rule errors. In this case, the batch processing is automatically terminated and an alarm is triggered, requiring manual intervention for investigation. Through this risk blocking mechanism based on statistical proportions, group-level quality monitoring can be achieved with extremely low computational overhead. This avoids the inefficiency of verifying each customer individually and can sensitively capture batch decision deviations, thereby improving the quality of credit assets and business security.

[0088] It should be noted that when granting credit to customers who have passed the formal access results table, the data sources and credit calculation formulas required for different credit products vary. For example, AP products require average monthly revenue and existing liabilities, BP products require credit scores and monthly income, and CP products require supply chain transaction volume and payment terms. In the traditional implementation, developers write hard-coded data retrieval logic and credit calculation formulas separately for each credit product, resulting in high code coupling, long credit product development cycles, and high maintenance costs. Therefore, to decouple the data retrieval logic and credit calculation formulas of credit products, further, as an optional implementation method, refer to... Figure 13 As shown, Figure 13 The credit granting process flowchart shows that step S1250 specifically includes: In step S1310, the credit code corresponding to the credit product of the customer to be granted credit, the credit data code corresponding to the credit code, and the data parsing script are determined.

[0089] In step S1320, the data center is invoked based on the credit data encoding, and the data center collects the original credit data based on the data source encoding and customer identifier.

[0090] In step S1330, the original credit data is converted into a standardized data object using the data parsing script.

[0091] In step S1340, the current credit limit is determined using the standardized data object and the credit logic corresponding to the credit code.

[0092] In step S1350, the current credit limit and the customer identifier of the customer to be granted credit are stored in the pre-credit result table.

[0093] In step S1360, for customers awaiting credit granting who already have credit limits in the pre-credit granting result table, if the proportion of customers awaiting credit granting whose current credit limit is less than a preset threshold is less than a preset threshold, then a credit granting operation is performed.

[0094] In this embodiment, the credit granting code can be a code used to identify the credit granting calculation scenario. It is usually bound to a specific credit granting product and is used to associate the credit granting data, data parsing scripts, and credit granting logic formulas required by the credit granting product. The credit granting data code can be a code corresponding to the credit granting code and used to identify the source of the original data required for credit granting calculation. Each credit granting data code corresponds to a database table, and one credit granting code can be associated with multiple credit granting data codes.

[0095] Specifically, customers whose admission results have been approved can be selected from the updated official admission result table and used as the targets for this credit granting operation. Subsequently, based on the credit product applied for by the customer, the corresponding credit code can be queried from the credit configuration library, and based on the credit code, the associated credit data code and the data parsing script corresponding to each credit data code can be obtained from the credit configuration library.

[0096] After obtaining the credit data code, the unified data center can be accessed. The data center can collect the original credit data from the corresponding database tables based on the customer identifier and the credit data code. For example, based on the credit data code and the customer identifier, the average monthly credit receipts of customers to be granted credit can be obtained from the transaction summary table, and the existing liabilities can be obtained from the balance sheet.

[0097] After collecting the original credit data of each customer awaiting credit, the corresponding data parsing script can be invoked according to the data code to convert the original data into a standard data object. This standardized data object is then passed to the credit granting logic corresponding to the credit code to calculate the credit limit. Subsequently, the customer identifier, calculated credit limit, and timestamp of each customer are written into the pre-credit granting result table.

[0098] After updating the pre-approval credit result table, for customers awaiting credit granting who already have credit limits in the table, the system calculates a first number of customers with existing credit limits and a second number of customers whose difference between their existing credit limit and current credit limit exceeds a preset difference. The second number is then counted as a percentage of the first number. If this percentage is less than a preset threshold, the verification is considered successful, and credit granting is initiated for the customers in the pre-approval credit result table. If this percentage is greater than the preset threshold, an abnormal decrease in credit limit or an abnormal increase in credit limit is identified, the verification fails, an alarm is triggered, and the formal credit granting process is terminated.

[0099] In this embodiment, the credit granting code serves as the unique identifier for the credit granting product, associating it with all the credit granting data codes required by the product and the corresponding data parsing scripts. The credit granting logic is independently configured as formulas or rules. During pre-credit granting, these configurations are dynamically loaded based on the credit granting code, data is collected concurrently from the data center, the data is standardized using the parsing script, and then the credit granting logic is invoked to calculate the credit limit. This design transforms the credit granting development of the product into a purely configuration-based task: only the credit granting code needs to be registered, the data source associated, and the parsing script and credit granting formula written; no data retrieval or calculation code needs to be written. When the credit granting logic of the product changes, risk control personnel can directly modify the credit granting formula or parsing script in the management backend. The changes take effect immediately without requiring a service restart or a deployment process, avoiding the testing costs and deployment risks associated with code modifications in traditional solutions.

[0100] In addition, by pre-calculating the pre-approved credit limit and storing it in a separate pre-approved result table, and then comparing it with the current official credit limit on a customer-by-customer basis, using the percentage of customers whose credit limit decreases by more than a preset percentage as the judgment criterion, it can sensitively detect systemic credit limit anomalies caused by data source distribution drift, unit conversion errors, or misconfiguration of the credit granting formula. In other words, a large-scale decrease in credit limit is the most sensitive indicator of data anomalies or logical errors. If the credit limit of all customers decreases systematically, it indicates that the upstream data may have shifted overall or the coefficients in the credit granting formula may have been mistakenly modified; if only a few customers' credit limits decrease, it is considered normal individual fluctuation. By setting a percentage threshold, systemic risks and individual differences can be distinguished, thereby automatically blocking the batch processing process before errors affect real customers, eliminating production accidents caused by large-scale errors in credit limit at the simulation stage, and ensuring the safety and reliability of credit granting decisions.

[0101] Meanwhile, this embodiment also provides an electronic device, which includes: One or more processors; A memory having stored one or more computer programs thereon, which, when executed by the one or more processors, cause the one or more processors to implement the trust processing method according to the first aspect of the invention.

[0102] The electronic device may also include one or more I / O interfaces connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0103] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the first memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, enabling information exchange between the processor and the memory, including but not limited to the data bus (Bus).

[0104] In some embodiments, the processor, memory, and I / O interfaces are interconnected via a bus, and thus connected to other components of the computing device.

[0105] As a third aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the trust processing method provided in the first aspect of the present disclosure.

[0106] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. Accordingly, the computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can implement the methods of any of the above embodiments. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0107] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the contents described in the accompanying drawings and the specific embodiments above. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.

Claims

1. A credit granting processing method, characterized in that, include: Obtain customer data of customers to be granted credit, and store the customer data in a synchronization table; The customer data in the synchronization table is subjected to integrity verification, format validity verification, and distribution consistency verification to obtain the customer data verification results. If the customer data verification result is successful, the customer data in the synchronization table will be synchronized to the business table; The customer data in the business table is verified using the pre-admission decision rules to obtain the pre-admission result of the customer to be granted credit. If the pre-approval result of the customer to be granted credit is approved, the credit granting operation is performed on the customer to be granted credit.

2. The credit processing method according to claim 1, characterized in that, The steps of performing integrity verification, format validity verification, and distribution consistency verification on the customer data in the synchronization table to obtain the customer data verification results include: The customer data in the synchronization table is subjected to integrity verification, format validity verification, and distribution consistency verification to obtain integrity verification results, format validity verification results, and distribution consistency verification results. If the integrity verification result, the format validity verification result, and the distribution consistency verification result are all passed, the customer data verification result is determined to be passed.

3. The credit processing method according to claim 2, characterized in that, The steps of performing integrity verification, format validity verification, and distribution consistency verification on the customer data in the synchronization table to obtain integrity verification results, format validity verification results, and distribution consistency verification results include: If the difference between the number of data rows in the synchronization table and the average number of rows in the preset time period does not exceed the preset difference, and the null value rate of the customer identifier in the synchronization table is not greater than the preset null value rate, the integrity verification result is passed. If the total transaction amount of all the customers to be granted credit in the synchronization table is not less than the preset amount, and the transaction identification information in the synchronization table is not duplicated, the format legality verification result is passed; If all numerical customer data metrics are within their corresponding preset ranges in the synchronization table, the distribution consistency check result is passed.

4. The credit processing method according to claim 1, characterized in that, The step of using pre-admission decision rules to perform admission verification on the customer data in the business table to obtain the pre-admission result of the customer to be granted credit includes: Determine the pre-access rule identifier corresponding to the credit product of the customer to be granted credit; Determine the pre-admission decision rule corresponding to the pre-admission rule identifier; The business feature values ​​corresponding to each of the pre-admission decision rules are extracted from the business table using the pre-admission rule identifier. Replace the feature placeholders in the expression of the pre-admission decision rule with the corresponding business feature values ​​to obtain the pre-admission decision rule expression; For each of the pre-admission decision rule expressions, a decision judgment is made to obtain the decision result corresponding to each of the pre-admission decision rule expressions; If all the aforementioned decision results are passed, the pre-admission result of the customer to be granted credit is determined to be passed.

5. The credit processing method according to claim 4, characterized in that, The business table corresponds to the business data type, the business data type corresponds one-to-one with the business data code, the business data code corresponds to multiple feature codes, the feature codes correspond one-to-one with Groovy scripts, and the Groovy scripts are used to convert the business data corresponding to the feature codes into business feature values. The step of extracting the business feature values ​​corresponding to each of the pre-admission decision rules from the business table using the pre-admission rule identifier includes: Determine the business data code corresponding to the pre-admission rule identifier, and the feature code corresponding to the business data code; Using the customer identifier of the customer to be granted credit and the business data code, read the corresponding business data from the corresponding business table; The Groovy script corresponding to the feature code is invoked to convert the corresponding business data into business feature values.

6. The credit granting processing method according to claim 5, characterized in that, The step of reading the corresponding business data from the corresponding business table using the customer identifier of the customer to be granted credit and the business data code includes: When the business data type corresponding to the business data code is list configuration data, the data warehouse interface is called to extract the corresponding list configuration identifier from the list configuration warehouse based on the customer identifier; wherein, the list configuration warehouse is a mapping table consisting of the customer identifier and the list configuration identifier.

7. The credit processing method according to claim 1, characterized in that, The steps for granting credit to the customer who is to be granted credit if the pre-approval result is approved include: Store the pre-approval results of each of the aforementioned customers awaiting credit in the pre-approval result table; The percentage of candidates who passed the pre-admission result in the pre-admission result table is determined as the first proportion. The current effective official admission results table determines the second percentage of admissions passed. If the difference between the first percentage and the second percentage is less than a preset threshold, the credit granting operation is performed on the customers whose pre-approval result is passed, and the formal admission result table is updated using the pre-approval result table. Credit granting operations will be performed on the approved customers pending credit granting results in the updated official admission results table.

8. The credit processing method according to claim 7, characterized in that, The steps for performing credit granting operations on the approved customers in the updated official access result table include: Determine the credit code corresponding to the credit product of the customer to be granted credit, the credit data code corresponding to the credit code, and the data parsing script; The data center is invoked based on the credit data encoding, and the data center collects the original credit data based on the data source encoding and customer identifier. The raw credit data is converted into standardized data objects using the data parsing script. The current credit limit is determined using the standardized data object and the credit granting logic corresponding to the credit granting code; Store the current credit limit and the customer identifier of the customer to be granted credit in the pre-credit result table; For customers awaiting credit granting who already have credit limits in the pre-credit granting result table, if the proportion of customers awaiting credit granting whose current credit limit is less than a preset threshold is less than a preset threshold, then the credit granting operation is performed.

9. An electronic device, characterized in that, include: One or more processors; A memory having stored one or more computer programs thereon, which, when executed by the one or more processors, cause the one or more processors to implement the trust processing method according to any one of claims 1 to 8.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the credit processing method according to any one of claims 1 to 8.

Images