Account rating management method and system based on account credible authentication
By building a trusted account profile and using the GBDT integrated learning model to assess account risk levels, the shortcomings of existing credit limit management solutions are addressed, flexible and efficient risk control and credit limit management are achieved, and the security of financial transactions and user experience are improved.
Patent Information
- Application Number
- CN202510492354.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-18
- Publication Date
- 2025-09-19
AI Technical Summary
Existing quota management solutions have shortcomings in terms of risk control flexibility, regulatory requirements for non-compliant capital chains, and dynamic limit management, and cannot meet the high requirements for flexibility and precision in modern financial transactions.
By extracting account information from the data warehouse, building account trust files, combining account flow data to conduct risk level assessment, using the GBDT integrated learning model to assess account risk and trust level, and dynamically adjusting the credit limit, accurate risk control and credit limit management can be achieved.
It achieves more comprehensive, flexible and efficient risk control and quota management, improves the security of financial operations and user experience, and can effectively respond to changing transaction risks.
Smart Images

Figure CN120672451A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a credit limit management method, and more specifically to an account credit limit management method and system based on account trusted authentication. Background Art
[0002] Limit management plays a crucial role in financial transactions, effectively controlling account risk and preventing misuse and fraud. Scientific limit management allows precise setting of limits based on account risk levels, thereby mitigating potential losses and protecting user funds. However, existing limit management solutions still have limitations in practice and cannot fully meet the high demands for flexibility and precision in modern financial transactions. To better manage risk and address emerging threats such as non-compliant content, current limit management solutions have exposed several shortcomings, primarily in determining overall account risk, dynamically adjusting limits, and efficiently processing large amounts of data.
[0003] Specifically, there are three existing credit limit management solutions. The first simply compares the current transaction corresponding to the user ID with historical transaction information and the target merchant information to determine the probability that the current transaction is the user's own, thereby determining the transaction's credibility. However, each transaction must be compared with historical data. If the comparison is insufficient, a trusted transaction may be mistakenly identified as untrusted. If the amount of data to be compared is large, the computational complexity will also increase, affecting the system's processing efficiency.
[0004] The second solution determines the risk control outcome of the current transaction based on the target entity's initial risk control decision and the transaction's credibility. Transaction credibility is determined based on a pre-built profile of the customer's credibility factors. While this solution can help determine whether a transaction is risky or trustworthy, its decision-making process solely relies on the transaction's credibility level to determine risk control measures such as password-free authentication, SMS verification, or facial recognition, without considering the account's overall credibility. Therefore, this solution cannot meet the following requirements: Financial institutions such as banks and third-party payment platforms must implement stricter risk management on related accounts when managing non-compliant "capital chains," such as reducing non-over-the-counter credit limits. Existing solutions are not suitable for determining the overall credibility of accounts and cannot effectively implement dynamic credit limit management for risky accounts.
[0005] The third solution limits account limits based on pre-set oracle configuration tables and rules. This approach calculates account limits for account transaction scenarios through a step-by-step evaluation process. However, this solution, which sets limits solely through a fixed account limit parameter table, fails to effectively address dynamic limit requirements for high-risk accounts with non-compliant "capital chains." For users with low-limit accounts, effective risk assessment and limit calculation are impossible when their limits are increased. For example, some financial institutions implement a uniform limit control policy for accounts with no transactions, such as a 5,000 RMB limit for accounts with no transactions for six months. This fails to flexibly address specific account circumstances.
[0006] In summary, the existing solutions have obvious deficiencies in terms of risk control flexibility, regulatory requirements for responding to non-compliant capital chains, and dynamic limit management.
[0007] Therefore, it is necessary to design a new method to achieve more comprehensive, flexible and efficient risk control and quota management, which can better cope with various transaction and account risks and improve financial security and user experience. Summary of the Invention
[0008] The purpose of the present invention is to overcome the defects of the prior art and provide an account limit increase management method and system based on account trusted authentication.
[0009] To achieve the above objectives, the present invention adopts the following technical solution: an account limit increase management method based on account trusted authentication, comprising:
[0010] Extract account information from the data warehouse, extract trust factors, and build a trustworthy account profile;
[0011] Get account transaction data;
[0012] Evaluate the account risk level based on the account trust file and the transaction data to obtain the account risk level;
[0013] Determine a credit limit increase decision based on the account risk level to obtain a decision result;
[0014] When the decision result is passed or manual service, the transaction data is input into the account trust rating model for trust level assessment to obtain the account trust level;
[0015] Obtain account-related information;
[0016] Calculate the account balance based on the account credibility level and the account-related information to obtain a calculation result;
[0017] Output the account risk level and calculation results.
[0018] A further technical solution is: extracting account information from the data warehouse and extracting trust factors to build a trustworthy account profile, including:
[0019] Extract account information from the data warehouse, extract identification features of different trust factors, and assign a feature weight to each trust factor;
[0020] Determine whether each of the trust factors meets the trust criteria based on the set identification strategy, filter the trust factors that meet the trust criteria and save them in the archive, and assign a trust weight score to obtain the account trust archive.
[0021] Its further technical solution is: the trust factors include counterparties, transaction amount range, and transaction frequency.
[0022] A further technical solution is that the trust weight score in the trust file of the account gradually decays over time.
[0023] Its further technical solution is: the account credibility rating model is constructed by feature engineering historical operation behavior and transaction flow data, identifying account credibility factors, and training using the GBDT integrated learning model.
[0024] A further technical solution is as follows: the training process of the account credibility rating model includes:
[0025] Obtain historical operation behavior flow data and account transaction flow data to obtain a sample set;
[0026] Preprocessing the sample set to obtain a first preprocessing result;
[0027] Identifying account trust factors based on the first preprocessing result and generating corresponding trust features to obtain trust factor features;
[0028] Build an integrated learning model based on GBDT;
[0029] The trust factor features are input into the GBDT-based integrated learning model for training to obtain an account trust rating model.
[0030] A further technical solution is: identifying the account trust factor based on the first preprocessing result and generating a corresponding trust feature to obtain a trust factor feature, including:
[0031] identifying account credibility factors based on the first preprocessing result to obtain basic features;
[0032] Expanding and transforming the basic features to obtain expanded results;
[0033] Feature selection is performed from the expanded results to obtain corresponding credible features, so as to obtain credible factor features.
[0034] A further technical solution is: the account risk level is assessed based on the account trust file and the transaction data to obtain the account risk level, including:
[0035] An account risk rating model is used to evaluate the account risk level to obtain the account risk level, wherein the account risk rating model is a model trained by using historical operation behavior flow data and dynamic account transaction flow data using the GBDT ensemble learning method.
[0036] A further technical solution is: calculating the account limit based on the account credibility level and the account-related information to obtain a calculation result, including:
[0037] The account credibility level and the account-related information are input into the credit limit calculation matrix to calculate the account credit limit to obtain a calculation result; wherein, the account-related information includes the customer value level, the customer credit loan limit, the customer's AUM, the maximum value of the account's habitual daily transaction amount range in the account credibility file, and the bank's maximum non-counter limit.
[0038] The present invention also provides an account credit management system based on account trusted authentication, including:
[0039] A trusted profile building unit is used to extract account information from the data warehouse, extract trust factors, and build a trusted account profile;
[0040] Behavior acquisition unit, used to obtain account transaction data;
[0041] a risk assessment unit, configured to assess the account risk level based on the account trust file and the transaction data to obtain the account risk level;
[0042] A decision-making unit, configured to determine a credit limit increase decision based on the account risk level to obtain a decision result;
[0043] a trust evaluation unit configured to input the transaction data into an account trust rating model to perform a trust level evaluation to obtain an account trust level when the decision result is pass or manual service;
[0044] An information acquisition unit, used to acquire account-related information;
[0045] a calculation unit, configured to calculate the account limit based on the account trust level and the account-related information to obtain a calculation result;
[0046] The output unit is used to output the account risk level and the calculation result.
[0047] The beneficial effects of the present invention compared with the existing technology are as follows: the present invention extracts account information and trust factors from the data warehouse, constructs an account trust file, and evaluates the account risk level in combination with account transaction data, thereby achieving accurate risk identification and management; according to the account risk level, the system automatically makes a credit limit increase decision. When the decision is passed or manual service is required, the transaction data is input into the trust rating model for further evaluation to obtain the account trust level; finally, the credit limit is calculated in combination with the account trust level and related information, and the account risk level and credit limit calculation results are output; this method can comprehensively and flexibly respond to various transaction and account risks, and through precise risk control and credit limit management, it not only improves the security of financial operations, but also optimizes the user experience.
[0048] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS
[0049] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0050] Figure 1 A schematic diagram of an application scenario of the account limit increase management method based on account trusted authentication provided by an embodiment of the present invention;
[0051] Figure 2 A flowchart of an account limit increase management method based on account trusted authentication provided by an embodiment of the present invention;
[0052] Figure 3 A schematic diagram of autonomous sliding calculation of the time axis provided by an embodiment of the present invention;
[0053] Figure 4 A schematic diagram of attenuation and effectiveness calculation within an effective period provided by an embodiment of the present invention;
[0054] Figure 5 A schematic block diagram of an account limit increase management system based on account trusted authentication provided by an embodiment of the present invention;
[0055] Figure 6 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION
[0056] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.
[0057] It will be understood that when used in this specification and the appended claims, the terms “comprises” and “comprising” indicate the presence of described features, integers, steps, operations, elements and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.
[0058] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the present invention. As used in the specification and appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise.
[0059] It should be further understood that the term "and / or" used in the present description and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.
[0060] See also Figure 1 and Figure 2 , Figure 1 A schematic diagram of an application scenario of an account limit increase management method based on account trusted authentication provided by an embodiment of the present invention. Figure 2 A schematic flow chart of an account credit limit management method based on account trusted authentication provided in an embodiment of the present invention. The account credit limit management method based on account trusted authentication is applied to a server, which interacts with a terminal, and realizes more comprehensive, flexible and efficient risk control and credit limit management by extracting account information, building account trusted files, evaluating account risk levels and performing credit limit calculations. By extracting a variety of trusted factors (such as counterparties, transaction amount ranges, transaction frequencies, etc.) and assigning weights to them, combining historical operating behaviors and transaction flow data, a GBDT integrated learning model is used to perform risk rating and trust level assessment. This method not only adapts to risk changes by dynamically updating account files and weight scores, but also improves the security, accuracy and customer experience of financial products through accurate credit limit calculations and decision-making results (such as automatic credit limit increases or manual services). It can efficiently respond to changing transaction risks, optimize credit limit management and prevent potential risks.
[0061] Figure 2This is a flow chart of an account limit increase management method based on account trusted authentication provided by an embodiment of the present invention. Figure 2 As shown, the method includes the following steps S110 to S180.
[0062] S110: Extract account information from the data warehouse, extract trust factors, and build a trustworthy account profile.
[0063] In this embodiment, the account trust profile consists of three trust factors: the account's trusted subject, trusted habits, and trusted behavior. These factors are used to determine the account's trustworthiness, specifically the probability that the account has not participated and will not participate within a certain period of time, which is inconsistent with regulations. The trust factors in the trust profile are generated by executing a trust profile construction strategy using transaction and behavior data over the account's lifetime.
[0064] T Daily Active Accounts refer to accounts that have active transactions such as login, transfer, payment, and bill payment on the day before the execution of the account trust profile construction.
[0065] The trust factor is the minimum factor used to determine whether an account is trustworthy, and includes trusted devices, trusted counterparties, resident cities, customary transaction amount ranges, customary transaction types, and a list of trusted behaviors.
[0066] Account credibility refers to the likelihood that an account will not engage in non-compliant financial activities. The higher the account credibility, the lower the likelihood of engaging in such non-compliant financial activities. When rating accounts, accounts with higher credibility levels are assigned higher ratings.
[0067] This step specifically includes extracting account information from the data warehouse, extracting the identification features of the trust factors, and assigning feature weights to each trust factor. Then, based on the set identification strategy, it determines whether each trust factor meets the trust standards, saves the trust factors that meet the standards into the account trust file, and assigns a trust weight score.
[0068] The credibility factors include counterparty, transaction amount range, and transaction frequency.
[0069] The trust weight score in the account trust profile gradually decays over time.
[0070] In one embodiment, the aforementioned step S110 may include steps S111 - S112 .
[0071] S111. Extract account information from the data warehouse, extract identification features of different trust factors, and assign a feature weight to each trust factor.
[0072] In this embodiment, relevant account information needs to be extracted from the data warehouse center of the financial institution's big data platform, including the following data:
[0073] Basic customer information such as customer number and account number.
[0074] Account operation and transaction data across all channels. Specifically, this includes data from mobile banking, personal online banking, UnionPay, and China National Nets Union.
[0075] Account transaction information and operation records, including transaction time, transaction amount, transaction type, transaction status, etc.
[0076] Customer's device information, IP address and city of origin, GPS location information, counterparty account and other data.
[0077] This step aims to extract key account data across various dimensions. This data will be used to generate identifying features for the trust factor. By analyzing this raw data, we can identify behavioral characteristics of each account, such as transaction amount and frequency. Furthermore, feature extraction must be combined with historical data to ensure that the extracted features accurately reflect the account's behavioral patterns and trustworthiness.
[0078] S112. Determine whether each of the trust factors meets the trust criteria according to the set identification strategy, select the trust factors that meet the trust criteria, save them into the archive, and assign a trust weight score to obtain the account trust archive.
[0079] In this embodiment, in step S112, the account trust factor identification strategy is first executed according to a preset standard. This standard is obtained by feature engineering calculations of the account trust factor. These features include the account's trusted subject, trusted behavior, trusted habits, etc. Specific standards may include the following judgments:
[0080] Trusted entities: whether trusted counterparties, trusted equipment, and permanent city of residence meet the standards.
[0081] Credible behavior: such as whether the user regularly pays for living expenses, credit card payments, mortgage payments, etc.
[0082] Trusted habits: such as habitual single transaction amount, daily transaction frequency, monthly transaction frequency, etc.
[0083] The criteria for each trust factor need to be quantified based on different account behaviors. At this point, the system will judge each factor according to the set strategy. Factors that meet the trust criteria will be screened and saved to the account trust profile, and a trust weight score will be assigned to them.
[0084] The weight of a credibility factor reflects the degree of influence of that factor on the account's credibility. Generally, some factors (such as transaction amount range and account activity) may have a greater impact on account credibility than others (such as the account's permanent city of residence), so their weights may be higher.
[0085] Ultimately, all trusted factors that meet the standards will be stored in the account's trusted archive, recording relevant information such as effective date, expiration date, status, etc. This process is completed through automated tasks and ensures that the system always keeps the account updated in real time.
[0086] For the above steps S111 to S112, the execution cycle of the account trusted profile construction strategy can be set to daily, and its execution mechanism is: on day T+1, the profile construction strategy is batch executed for the daily active accounts on day T, and the pre-set management mechanism is executed for the non-daily active accounts on day T.
[0087] An account's trustworthy profile contains three types of trustworthy factor data: trusted subjects, trusted behaviors, and trusted habits. This data is used to assess the trustworthiness of an account, i.e., to determine whether the account has engaged in or will engage in non-compliant activities within a certain period of time. Specifically, trusted subjects in an account's trustworthy profile include trusted counterparties, trusted devices, permanent cities, customary GPS positioning (accuracy 100 meters), trusted uses, etc.; trusted habits cover single transaction amount ranges, daily transaction amount ranges, monthly transaction amount ranges, daily transaction frequency, monthly transaction frequency, etc.; trusted behaviors involve periodic living expenses, periodic credit card repayments, periodic mortgage repayments, periodic social security contributions, periodic provident fund contributions, periodic deposits, and periodic insurance premiums.
[0088] At midnight each day, the financial institution's big data platform extracts data from the central data warehouse and processes the account trust factor characteristic variables. Once processed, the corresponding device is notified. The data extraction process includes fields such as customer number, account number, transaction time, device number, IP address, IP city, GPS address (to two decimal places), counterparty account, transaction type, transaction amount, and transaction status.
[0089] When calculating the characteristic variables for account credibility factors, data from untrusted time periods must be excluded. This untrusted time period refers to transaction data within two calendar days from the date (T) when the account credibility profile construction strategy was executed. This feature engineering approach is based on an analysis of basic customer information, account information, operational behavior, and transaction flow data from a sample of trusted accounts. This extracts identifying features for each credibility factor and ultimately combines them into the account credibility factor data, as shown in Table 1.
[0090] Table 1. Account credibility factor data
[0091]
[0092]
[0093] When the big data platform completes the task, the device obtains the trust factor characteristic variable through the workflow component and executes the account trust profile construction task.
[0094] The strategy for building an account trust factor profile is to design identification criteria for each trust factor based on its identifying characteristics. For trust factors that meet these criteria, the system will enter them into the account trust factor profile. During entry, in addition to account information, trust factor data, the trust factor's effective date (update date), and status, a trust weight score is assigned based on the factor's trustworthiness. This is shown in Table 2.
[0095] Table 2. Account Credibility Factor Profile
[0096]
[0097] For account trust factors that already exist in the archive, only their effective date, expiration date, and trust factor interval need to be updated; otherwise, a new account trust factor record is added.
[0098] An account trust profile consists of the following information: account number, trust factor, trust data, trust score, effective date, expiration date, status, interval, and expiration period. The effective date refers to the date when the account trust profile construction strategy was last hit. For example, if the trusted counterparty for account number "622718130287555555" is "A1," the trust score is 100, the data entry date is January 1, 2025, and the expiration period is 12 months, this means that the data will expire on December 30, 2025. This is shown in Table 3.
[0099] Table 3. Account Trust Profiles
[0100]
[0101]
[0102] In the above steps, once a trusted factor matches the identification policy and is entered or updated, the device will continue to manage other statuses and trusted factor weight scores in the account archive. First, it is necessary to determine whether the trusted factors of all accounts should be invalidated. This expiration determination is based on a comparison of the trusted factor's expiration date with the T+1 date. If the T+1 date exceeds the expiration date, the trusted factor's status is updated to invalid.
[0103] For trust factors that have not expired, the trust factor weighting is calculated based on the time interval between each execution of the account trust profile construction strategy and the last update date of the factor. This time interval is divided into three categories: long-term, medium-term, and near-term. Depending on the interval, the trust factor weighting will gradually decrease, from the near-term to the long-term.
[0104] Specifically, the credibility of the near-term factors has a higher credibility weight score and is more credible; the credibility of the medium-term factors is relatively general, and the weight score is lower than that of the near-term; while the credibility of the long-term factors is weakened, and the weight score is further reduced than that of the medium-term. Figure 3 As shown in Figure 2, the credibility of an account will gradually decay over time, and the specific degree of decay will be adjusted according to the time interval division of each type of factor.
[0105] In the management process, Figure 4 As shown, the interval (near-term, mid-term, and long-term) is an important data item that helps determine the strength of the trust factor. Each time the account trust profile construction strategy is executed, the weight and trustworthiness of the factor are adjusted based on the interval between the factor update date and the execution date.
[0106] In this way, the system can flexibly manage the attenuation of the account's credibility factor, ensuring that the credibility of the account file remains accurate and timely.
[0107] S120: Obtain account transaction data.
[0108] In this embodiment, account flow data includes operational flow data and transaction flow data. Operational flow data refers to all operations related to account management and use performed by the account holder over a period of time. This type of data is mainly used to describe the daily use of the account, and generally includes but is not limited to the following:
[0109] Login and logout records: when the account was logged in and out, the user's IP address, device information, login location, etc.
[0110] Operational behavior: such as account fund inquiry, account setting change, password modification, personal information update, etc.
[0111] Access path: The user's behavior track when operating an account, including the pages browsed, operations performed, etc.
[0112] This operational behavior data can reflect the activity and frequency of account usage, as well as any abnormal behavior. For example, frequent password changes or unusual login locations may indicate that the account is at risk of being stolen or maliciously manipulated.
[0113] Transaction flow data refers to the transaction records involving the flow of funds in an account, including all transactions such as deposits, withdrawals, transfers, payments, and receipts. This type of data is more directly related to the account's financial status and typically includes:
[0114] Cash inflow: such as deposits, transfers, income, etc.
[0115] Outflow of funds: such as withdrawals, transfers, bill payments, consumption, etc.
[0116] Transaction amount: The amount, currency, and other information of each transaction.
[0117] Counterparty: The other party's account to which funds are transferred in or out, which may be a personal account, a corporate account or a third-party platform.
[0118] Transaction time and status: The time when the transaction occurred and the status of whether it was successful (for example, successful, failed, pending, etc.).
[0119] The transaction flow data of the dynamic account is used to monitor the flow of funds in the account and identify whether there are any abnormal fund operations.
[0120] S130: Evaluate the account risk level based on the account trust file and the transaction data to obtain the account risk level.
[0121] In this embodiment, the account risk level refers to the possibility that the account's participation is not in compliance with regulations, and the higher the possibility, the higher the risk level. When rating accounts, accounts with high risk levels are assigned lower account ratings.
[0122] An account risk rating model is used to evaluate the account risk level to obtain the account risk level, wherein the account risk rating model is a model trained by using historical operation behavior flow data and dynamic account transaction flow data using the GBDT ensemble learning method.
[0123] Specifically, during the construction of account risk identification feature engineering, we need to extract risk features that can reflect the account's involvement in non-compliant activities from the account's historical operation behavior flow and account transaction flow, classify them from low to high risk, and build an effective feature identification system. The specific steps are as follows:
[0124] First, you need to clean the account's historical operation flow and transaction flow. This step aims to ensure data quality. Common methods include:
[0125] Fill missing values: Fill the empty values in the data by using the mean, median, or other appropriate methods to avoid analysis bias caused by missing data.
[0126] Remove abnormal data: Identify and remove unreasonable data points, such as extreme outliers or erroneous records.
[0127] Data standardization and normalization: Convert the data to a uniform scale to ensure that different features have equal influence when processed by the model.
[0128] Next, we analyze and extract typical characteristics of the risky accounts in the training set. These characteristics will serve as a preliminary feature set for subsequent feature construction and model training. By deeply analyzing account operations and transaction flows, we can identify potential risk patterns.
[0129] Based on the basic feature set, further feature engineering is needed to construct richer features to improve the performance and interpretability of the model. Common feature construction methods include:
[0130] Binning: Convert continuous variables into discrete intervals to simplify data representation.
[0131] Feature intersection and combination: By combining different features, new composite features are generated to capture more complex nonlinear relationships.
[0132] Polynomial expansion: Generate higher-order terms of features to reveal more complex patterns.
[0133] Categorical feature processing: Encode the categorical variables, such as using one-hot encoding, to convert the categorical features into numerical data. The features shown in Table 4 are obtained.
[0134] Table 4. Violation characteristics
[0135]
[0136]
[0137] In order to improve the efficiency and effectiveness of the model, it is necessary to select the most discriminative and effective features from a large number of constructed features. Common feature selection methods include:
[0138] Filtering method: Filter based on the correlation between features and target variables or other statistical indicators.
[0139] Variance thresholding: Remove features with low variance, which provide less information.
[0140] Correlation analysis: Remove highly correlated features to prevent redundant information from affecting the model.
[0141] Wrapping method and recursive feature elimination: gradually filter features by recursively training the model and evaluating the importance of features.
[0142] Embedding method: Use the feature selection mechanism of certain models (such as Lasso regression, decision tree, etc.) to screen features.
[0143] Tree model feature importance: Calculate the importance of features through tree models (such as random forest, XGBoost, etc.) and select the most meaningful features.
[0144] Through these steps, a streamlined and efficient feature set is finally built to effectively identify account risks, especially those involving non-compliant activities.
[0145] S140: Determine a credit limit increase decision based on the account risk level to obtain a decision result.
[0146] In this embodiment, the decision result refers to the determination result of whether the account limit is allowed to be increased.
[0147] In Table 4, the risk score of each violation feature is assigned based on the actual business risk verification results. Common features serve as the basic risk score for other feature categories, and other feature categories will further add points based on the common feature scores. The score of each category of features will ultimately take the higher value. The score range is divided into low-risk accounts (0-40 points), medium-risk accounts (41-80 points) and high-risk accounts (80 points and above). Different decision-making processes are adopted according to the risk level of the account:
[0148] Low-risk account: When an account is judged to be low-risk, its credit limit increase application will be directly approved (ACCEPT).
[0149] Medium-risk accounts: When an account is medium-risk, the credit limit increase application will be forwarded for manual review (REVIEW). The teller or back-office staff will conduct further due diligence on the customer and decide whether to approve the credit limit increase application based on the results of the review.
[0150] High-risk accounts: When an account is considered high-risk, its credit limit increase application will be directly rejected.
[0151] For accounts that have applied for a credit limit increase, the credit limit will be calculated and determined based on the credit limit calculation matrix.
[0152] S150: When the decision result is passed or manual service, the transaction data is input into the account credibility rating model for credibility rating assessment to obtain the account credibility rating.
[0153] In this embodiment, the account trustworthiness level refers to the degree of reliability that the account will not participate in illegal financial activities. The higher the account trustworthiness level, the lower the possibility of participating in the aforementioned illegal financial activities. When rating accounts, accounts with higher trustworthiness levels are given higher account ratings.
[0154] The account credibility rating model is constructed by performing feature engineering on historical operation behavior and transaction flow data, identifying account credibility factors, and training the model using the GBDT integrated learning model.
[0155] In one embodiment, the training process of the account credibility rating model includes steps S151 to S155.
[0156] S151. Obtain historical operation behavior flow data and account transaction flow data to obtain a sample set.
[0157] In this embodiment, the historical operation behavior flow data refers to all historical transaction records of the account, such as account fund inflows and outflows, transfer operations, deposits and withdrawals, and other information.
[0158] Transaction flow data refers to the data of each transaction record in the account, which may include changes in account balance, transfer records, expenditure and income information.
[0159] From the historical operational behavior and transaction flow data obtained, we extract qualified samples to form a sample set containing various account behaviors and transactions. This sample set will be used for subsequent feature engineering and model training.
[0160] S152: Preprocess the sample set to obtain a first preprocessing result.
[0161] In this embodiment, for any null values that may exist in the sample set, we use a filling method (such as mean filling) or delete the relevant records. We then check for abnormal data points (such as obviously incorrect transaction amounts) and take appropriate measures (such as deleting abnormal data or making corrections).
[0162] Standardize or normalize the data to make the scales of different features consistent and ensure that the features are at the same level, so as to avoid certain features from having too much influence on the model during subsequent model training.
[0163] The sample set is divided into a training set and a validation set. The training set is used to build feature engineering and train the model, while the validation set is used to evaluate the effect of the model.
[0164] The cleaned and standardized sample set is the first preprocessing result, which will provide the data basis for subsequent feature engineering and model training.
[0165] S153: Using an account trust factor profile generation strategy to identify the account trust factor for the first preprocessing result, and generating a corresponding trust feature to obtain a trust factor feature.
[0166] In one embodiment, the aforementioned step S153 may include steps S1531 to S1533.
[0167] S1531. Identify account credibility factors based on the first preprocessing result to obtain basic features;
[0168] S1532: Expand and transform the basic features to obtain an expanded result;
[0169] S1533. Perform feature selection from the expanded results to obtain corresponding trustworthy features, so as to obtain trustworthy factor features.
[0170] In this embodiment, the account's historical operation records and transaction flow are first cleaned. This includes using the mean to fill missing values or deleting abnormal data to ensure data standardization and normalization, thereby ensuring data quality.
[0171] Next, we analyze the behavioral characteristics of trusted accounts to identify factors that can effectively identify them. For example, we examine whether the account's counterparty is trustworthy, whether the transaction device is a commonly used device, whether the transaction amount is within a typical range, and whether the transaction location is a common trading area. These characteristics will serve as the basis for the account's credibility score.
[0172] Construct and transform the collected features. Generate new feature sets through binning, feature crossover, combining numerical and categorical features, and polynomial expansion to improve the model's expressiveness and interpretability. For example, analyze account transaction patterns, such as the regularity of amounts within a fixed period (such as salary, repayments, etc.), the frequency of transactions with trusted counterparties, and whether the account's daily transaction amount conforms to the usual range.
[0173] Finally, a streamlined and effective feature set is screened out through a variety of methods (such as filtering, variance threshold, correlation analysis, recursive feature elimination, tree model feature importance, etc.) to more accurately identify the credibility of the account.
[0174] Among them, the classification and specific features of trusted features are:
[0175] Trusted Subject:
[0176] Trusted counterparty: The account has a high proportion of transactions with the trusted counterparty, the transaction amount follows a fixed periodic pattern (such as salary deposits, repayments, etc.), or the counterparty's transfer amount accounts for a high proportion.
[0177] Trusted Purpose: There are multiple transactions with trusted purposes in the account, such as bank-futures transfers, bank-securities transfers, etc.
[0178] Trusted Habits:
[0179] Single transaction amount range: The proportion of transaction amounts within a single day that fall within the customary range is high.
[0180] Daily transaction amount range: The number of days when the account's daily transaction amount is within the customary range accounts for a high proportion.
[0181] Daily trading frequency range: The account's daily trading frequency is high and in line with the habitual frequency.
[0182] Trusted Behavior:
[0183] Periodic living expense payment: The account has periodic living expense payment records.
[0184] Periodic credit card repayments: The account has a regular credit card repayment record.
[0185] The details are shown in Table 5.
[0186] Table 5. Credibility factor characteristics
[0187]
[0188]
[0189] S154. Build an integrated learning model based on GBDT.
[0190] In this embodiment, GBDT (Gradient Boosting Decision Tree) is used as the model framework. GBDT is an ensemble learning method based on decision trees. It constructs multiple tree models through multiple iterations, and each tree is optimized based on the previous model to reduce errors.
[0191] GBDT gradually improves the prediction ability of the model by continuously fitting the residual of each round (that is, the prediction error of the previous tree), and finally takes the weighted sum of the prediction results of all trees as the final prediction output.
[0192] GBDT builds weak decision trees through multiple iterations, continuously optimizing the model's predictive capabilities. Its core principle is to use a gradient boosting framework: an initial decision tree predicts the target value, and subsequent trees fit the error based on the residual of the previous tree (i.e., the negative gradient direction of the loss function), continuously correcting the model's predictions. Ultimately, the final prediction is obtained by weighted summing the outputs of all trees.
[0193] Regularization techniques are used during training to prevent the model from overfitting and to ensure that the model can generalize well to new data.
[0194] S155: Use the trust factor features to input into the GBDT-based integrated learning model for training to obtain an account trust rating model.
[0195] In this embodiment, the trust factor features are used as input data and passed into the constructed GBDT ensemble learning model.
[0196] The GBDT model is trained using training set data, so that the model learns how to judge the trustworthiness rating of an account based on the various trust factor characteristics of the account.
[0197] Use validation set data to verify the model's prediction effect, calculate the model's accuracy, recall rate, F1 value and other evaluation indicators, and determine whether the model can accurately identify the credibility of the account.
[0198] If the model reaches the predetermined accuracy threshold on the validation set, the model can be officially defined as an account credibility rating model and can be applied to actual account credibility assessment tasks.
[0199] Through the above steps, the entire account trust rating model construction process is completed, including data collection, feature engineering, model training, evaluation and other links.
[0200] The trained model is validated using the validation set data and the model's prediction accuracy is calculated. If the model's prediction accuracy reaches the preset threshold, the model training is considered complete and can be used as the final account trust rating model.
[0201] Through multiple rounds of iterative optimization using the GBDT algorithm and incorporating trusted account data, the expected error is gradually reduced. Furthermore, regularization strategies prevent overfitting, thereby improving model accuracy and robustness. Ultimately, this model can provide accurate and reliable support for real-world decision-making processes.
[0202] In summary, through the combination of sophisticated feature engineering and GBDT ensemble learning model, the credibility of accounts can be evaluated efficiently and accurately, thus providing an important basis for subsequent risk control and decision-making.
[0203] For the training of the above-mentioned account credibility rating model, the historical operation behavior flow and transaction flow of the trusted account are analyzed to extract the characteristics of each credibility factor, thereby generating a feature engineering for identifying the credibility of the account, ensuring that the credibility from low to high can be effectively distinguished.
[0204] After building a comprehensive set of trustworthy features, each feature is assigned a different weight based on the weight distribution of account feature types, with the total weight coefficient being 1. After multiple performance verifications, a final rating score is calculated based on the account's trustworthiness score, ranging from 0 to 100. Based on the score range, the account's trustworthiness is divided into the following categories:
[0205] Untrustworthy: 0–20 points;
[0206] Low confidence (C1): 21–40 points;
[0207] Moderately credible (C2): 41–60 points;
[0208] Medium to high credibility (C3): 61–80 points;
[0209] High confidence (C4): 81–100 points;
[0210] The credibility of each account is divided and managed through this rating system, which is divided into four levels.
[0211] During the account risk decision-making process, when the decision result is either approved or transferred to manual review, the system will execute the account credibility rating model to output the account's credibility level. This level is divided into four categories: high credibility (C4), medium-high credibility (C3), medium credibility (C2), and low credibility (C1).
[0212] The account trust rating model analyzes historical operational behavior and transaction data to construct an account's trust profile and extract relevant features. The model is trained using the GBDT (Gradient Boosted Decision Tree) ensemble learning method. First, the system extracts samples from the historical behavior and transaction data of trusted accounts and divides the data into a training set and a validation set. The training set is then used to train the GBDT model to construct an account trust rating model. The model is then validated using the validation set data to evaluate its predictive accuracy. If the model's accuracy reaches a preset threshold, it is adopted as the final account trust rating model.
[0213] GBDT is an ensemble learning method that optimizes a model's predictive power by gradually building multiple weak decision trees. In this process, an initial tree is used to predict the target value, and each new tree is then fitted to the error of the previous tree's prediction (i.e., the negative gradient of the loss function). In this way, the predictions of multiple tree models are gradually corrected, and the final prediction is obtained through a weighted summation.
[0214] In this example, by using the GBDT algorithm, combined with trusted account data, and through multiple rounds of feature learning and model prediction optimization, the model's error is continuously reduced. Regularization techniques are also used to avoid overfitting, ensuring the model's high accuracy and robustness, thus providing strong support for account risk decision-making.
[0215] S160: Obtain account-related information.
[0216] In this embodiment, the account-related information includes customer value level, customer credit loan limit, customer AUM, the maximum value of the account's habitual daily transaction amount in the account's trustworthy file, and the bank's maximum non-counter limit.
[0217] Specifically, a customer's value rating refers to a comprehensive assessment of a customer's value within a bank or financial institution. This assessment is typically based on multiple factors, including the customer's financial status, historical transaction history, and account activity. This rating reflects the customer's long-term relationship with the bank and the economic contribution they bring. This assessment allows banks to determine the appropriate service levels and credit limits for different customers.
[0218] High-value customers: These customers may have higher assets, good credit history, frequent transaction records, etc.
[0219] Low-value customers: These customers have limited account balances, historical transactions, loans, and other behaviors, and banks may classify them as low-value customers.
[0220] A customer's value tier often influences the initial credit limit setting. Customers with higher value tiers may be assigned higher credit limits because they have lower credit risk, higher assets, and are likely to remain with the bank for a longer period of time.
[0221] A customer's credit limit is the maximum loan amount a bank or financial institution sets for a customer. This limit is typically determined based on multiple factors, including the customer's credit profile, loan history, income level, and asset status. A higher credit limit means more funds a customer can borrow from the bank and reflects their creditworthiness.
[0222] Calculation of credit limit: The bank will comprehensively assess the customer's loan ability based on data such as the customer's credit score, debt-to-asset ratio, income situation, and repayment ability, and then set the credit limit.
[0223] Relationship with Account Limit: Credit limit is often a key factor in calculating account limits. If a customer's credit limit is high, the system may make appropriate adjustments to the credit limit when calculating the account limit to avoid exceeding the customer's repayment ability.
[0224] AUM (Assets Under Management) refers to the total assets managed by a client at a bank or financial institution, including deposits, investment products, funds, and wealth management products. A client's AUM is a key indicator of their wealth and investment capabilities.
[0225] The role of AUM: Generally speaking, clients with higher AUM tend to be high-net-worth individuals, who have lower credit risks and can afford higher borrowing limits. Banks consider clients' AUM when calculating credit limits and dynamically adjust them. For example, clients with higher AUM may be granted larger credit limits because their assets can serve as security for loan repayments.
[0226] Relationship with account limits: AUM typically affects the upper limit of an account limit. If a client's AUM increases, the system may automatically increase the account limit to match their wealth.
[0227] The maximum daily transaction amount range for an account refers to the largest single transaction amount in a customer's daily trading history. This data reflects the customer's trading behavior and the transaction size they typically handle. Over time, a customer's account will accumulate data on their trading habits, such as the daily transaction amount range and the types of frequent transactions.
[0228] Account habits: By analyzing a customer's historical transaction records, banks can understand their account usage habits. For example, some customers may frequently make large transactions, while others make smaller ones. Based on this information, banks can better predict customers' future transaction needs and adjust account limits accordingly.
[0229] The maximum daily transaction amount is the maximum amount a customer can typically trade in a single day. This is often used as a factor in determining the account limit. If a customer frequently trades large amounts, the system may increase their account limit to support their daily trading needs.
[0230] A bank's non-counter maximum limit refers to the maximum amount that can be processed in non-counter transactions within the banking system (e.g., transactions conducted through internet banking, mobile banking, telephone banking, etc.). Because non-counter transactions are more convenient than traditional counter transactions, banks typically manage and control their limits differently.
[0231] Characteristics of non-counter transactions: Non-counter transactions usually have higher flexibility, and customers can conduct transactions anytime and anywhere. Therefore, banks usually set the limit of non-counter transactions based on the customer's trust and risk assessment.
[0232] The role of limits: Banks set a maximum non-counter transaction limit to prevent excessive risk exposure. This limit is typically influenced by factors such as account level, customer creditworthiness, and historical transaction history. For example, customers with a good credit history and a high account balance may be eligible for a higher non-counter transaction limit.
[0233] During the account limit calculation process, all of the above information is combined for a comprehensive assessment. The system determines a base limit based on factors such as the customer's value rating, credit limit, and AUM. This limit is further adjusted based on the account's daily transaction maximum and the bank's maximum non-counter limit. For example, if a customer has large cash flow needs in their daily transactions, the system may increase their account limit to facilitate these transactions. At the same time, the bank ensures that credit limits, AUM, and other data are not overly inflated, thereby maintaining reasonable risk control.
[0234] This account-related information (customer value rating, credit limit, AUM, maximum daily transaction amount, and non-dealer maximum limit) is used to calculate and adjust account limits. By comprehensively considering this data, banks can set a reasonable and dynamically adjusted account limit for each customer, effectively balancing customer needs and risk management.
[0235] S170: Calculate the account limit based on the account credibility level and the account-related information to obtain a calculation result.
[0236] In this embodiment, the calculation result refers to the balance of the calculation account.
[0237] The account credibility level and the account-related information are input into the credit limit calculation matrix to calculate the account credit limit to obtain a calculation result.
[0238] In real-time risk decision-making and limit calculation requests for account limits, data such as the customer's value rating, credit limit, and AUM (Assets Under Management) are uploaded to the business system. However, in the limit calculation process of the present invention, this data is not directly included internally, but is passed as input to the system for limit calculation.
[0239] The account limit calculation matrix is based on two data dimensions: the account's trustworthiness rating and the customer's value rating. These two factors together determine the size of the account limit. This means that if a customer's account is rated higher in both trustworthiness and value, the system will automatically assign them a higher limit.
[0240] The matrix pre-defines a limit calculation rule, with different customer levels and account credibility levels corresponding to different positions in the matrix. At these positions, the matrix defines a formula for calculating the account limit. These formulas are typically adjusted based on the following factors:
[0241] The maximum value of the account's habitual daily transaction amount range: that is, the customer's largest single transaction amount in daily transactions.
[0242] The maximum limit of non-counter transactions at a bank is the upper limit of the account limit allowed by the banking system.
[0243] Client AUM (Assets Under Management): The total amount of assets owned by the client.
[0244] When the system calculates the account limit, it finds the corresponding position in the limit matrix based on the customer level and account credibility level, and applies the formula at that position to calculate the account limit. For example, if the account credibility level is C3 and the customer value level is V2, the system will find the formula at the position (V2, C3) in the matrix. For example, if the formula is as follows:
[0245] Credit limit = min(max((RESULT == ACCEPT?50000:20000)×2.5, max(account's maximum daily transaction amount, AUM)×6, credit loan limit), 1000000).
[0246] Among them, RESULT == ACCEPT? 50000:20000: This is a conditional judgment. If the result is "Accept", the basic limit is 50000, otherwise it is 20000.
[0247] ×2.5: This part may be used to adjust the credit limit based on the customer's historical performance or other factors.
[0248] max: This section calculates the account's maximum transaction amount or total assets under management, whichever is greater.
[0249] ×6: This part may be used to further adjust the credit limit based on the customer's AUM data.
[0250] Credit loan limit: This part limits the upper limit of the loan amount to ensure that the customer's credit limit is not exceeded.
[0251] min(1000000): The final calculated amount cannot exceed 1 million.
[0252] Through the above formula, the system will calculate the corresponding account limit in real time based on different customer data.
[0253] In the account limit calculation matrix algorithm, a customer's value rating, credit limit, and AUM information are submitted in real time to the business system for account limit increase risk decisions and limit calculations. The algorithm references existing customer data, customary account transaction amounts, the bank's maximum non-counter limit, and other information to perform real-time limit calculations based on the account's credibility level and customer's value level. According to the preset account limit calculation matrix, higher account credibility levels and customer value levels increase the account limit accordingly. During the calculation process, the customer level and account credibility level are first matched with the limit matrix. The account limit is then calculated using the calculation formula at the corresponding position in the matrix, and the limit range is ultimately determined, as shown in Table 6.
[0254] Table 6. Credit limit range
[0255]
[0256]
[0257] After calculating the account limit, the system makes a risk control decision based on the results. If the account limit increase request is approved, the system dynamically adjusts the customer's account limit. This decision and limit adjustment are fed back to the business system in real time, and the account limit is modified synchronously in the core system to ensure real-time adjustments.
[0258] By dynamically calculating customer account limits based on a pre-set limit calculation matrix using account credibility ratings, customer value ratings, and other relevant information, we enable real-time and flexible adjustments to account limits while ensuring a scientific and rational calculation process, avoiding human interference and improving risk control efficiency.
[0259] S180: Output the account risk level and the calculation result.
[0260] In this embodiment, a real-time calculation is performed based on various account data to determine the account's risk level. Next, the account's credit limit is calculated using information such as the account's trustworthiness rating and customer value rating. Ultimately, the system outputs the account's risk level and the corresponding credit limit.
[0261] The above-mentioned account credit limit management method based on account trust authentication extracts account information and trust factors from the data warehouse, constructs an account trust file, and evaluates the account risk level in combination with account transaction data, thereby achieving accurate risk identification and management; according to the account risk level, the system automatically makes a credit limit increase decision. When the decision is passed or requires manual service, the transaction data is input into the trust rating model for further evaluation to obtain the account trust level; finally, the credit limit is calculated in combination with the account trust level and related information, and the account risk level and credit limit calculation results are output; this method can comprehensively and flexibly respond to various transaction and account risks, and through precise risk control and credit limit management, it not only improves the security of financial operations, but also optimizes the user experience.
[0262] Figure 5 This is a schematic block diagram of an account credit management system 300 based on account trusted authentication provided by an embodiment of the present invention. Figure 5 As shown, corresponding to the above account credit limit management method based on account trust authentication, the present invention also provides an account credit limit management system 300 based on account trust authentication. The account credit limit management system 300 based on account trust authentication includes a unit for executing the above account credit limit management method based on account trust authentication, and the system can be configured in a server. Specifically, please refer to Figure 5 The account limit increase management system 300 based on account trusted authentication includes a trusted file construction unit 301, a behavior acquisition unit 302, a risk assessment unit 303, a decision unit 304, a trusted assessment unit 305, an information acquisition unit 306, a calculation unit 307 and an output unit 308.
[0263] The trusted profile construction unit 301 is used to extract account information from the data warehouse, extract trusted factors, and construct an account trusted profile; the behavior acquisition unit 302 is used to obtain the account's transaction data; the risk assessment unit 303 is used to assess the account risk level based on the account trusted profile and the transaction data to obtain the account risk level; the decision unit 304 is used to determine the credit limit increase decision based on the account risk level to obtain a decision result; the trusted assessment unit 305 is used to input the transaction data into the account trusted rating model for trusted level assessment when the decision result is pass or manual service to obtain the account trusted level; the information acquisition unit 306 is used to obtain account-related information; the calculation unit 307 is used to calculate the account limit based on the account trusted level and the account-related information to obtain a calculation result; the output unit 308 is used to output the account risk level and the calculation result.
[0264] In one embodiment, the trusted profile building unit 301 includes:
[0265] The feature extraction subunit is used to extract account information from the data warehouse, extract the identification features of different trust factors, and assign a feature weight to each trust factor;
[0266] The screening subunit is used to determine whether each of the trust factors meets the trust criteria according to the set identification strategy, screen the trust factors that meet the trust criteria, save them into the archive, and assign trust weight scores to obtain the account trust archive.
[0267] In one embodiment, the risk assessment unit 303 is used to assess the account risk level using an account risk rating model to obtain the account risk level, wherein the account risk rating model is a model trained using the GBDT ensemble learning method by utilizing historical operation behavior flow data and dynamic account transaction flow data.
[0268] In one embodiment, the calculation unit 307 is used to input the account credibility level and the account-related information into the credit limit calculation matrix to calculate the account credit limit to obtain a calculation result; wherein, the account-related information includes the customer value level, the customer's credit loan limit, the customer's AUM, the maximum value of the account's habitual daily transaction amount range in the account credibility file, and the bank's maximum non-counter limit.
[0269] It should be noted that technical personnel in the relevant field can clearly understand that the specific implementation process of the above-mentioned account increase management system 300 based on account trusted authentication and each unit can refer to the corresponding description in the aforementioned method embodiment. For the convenience and conciseness of the description, it will not be repeated here.
[0270] The above-mentioned account credit management system 300 based on account trust authentication can be implemented in the form of a computer program. The computer program can be used in Figure 6 Runs on the computer equipment shown.
[0271] See also Figure 6 , Figure 6 This is a schematic block diagram of a computer device provided in an embodiment of the present application. The computer device may be a server, wherein the server may be an independent server or a server cluster consisting of multiple servers.
[0272] See Figure 6 The computer device 500 includes a processor 502 , a memory, and a network interface 505 connected via a system bus 501 , wherein the memory may include a non-volatile storage medium 503 and an internal memory 504 .
[0273] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions, which, when executed, can enable the processor 502 to execute an account credit increase management method based on account trusted authentication.
[0274] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500.
[0275] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute an account increase management method based on account trusted authentication.
[0276] The network interface 505 is used to communicate with other devices through the network. Figure 6 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device 500 to which the solution of the present application is applied. The specific computer device 500 may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.
[0277] The processor 502 is configured to run a computer program 5032 stored in the memory to implement all steps of the above-mentioned account credit increase management method based on account trusted authentication.
[0278] It should be understood that in the embodiment of the present application, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.
[0279] Those skilled in the art will appreciate that all or part of the steps in the method of the above-described embodiment can be implemented by instructing the relevant hardware through a computer program. The computer program includes program instructions, which can be stored in a storage medium that is computer-readable. The program instructions are executed by at least one processor in the computer system to implement the steps in the method of the above-described embodiment.
[0280] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program, wherein when the computer program is executed by a processor, the processor performs all steps of the above-mentioned account credit increase management method based on account trusted authentication.
[0281] The storage medium may be any computer-readable storage medium that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, or an optical disk.
[0282] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.
[0283] In the several embodiments provided herein, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of the various units is merely a logical functional division, and actual implementations may employ other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented.
[0284] The steps in the method of the embodiment of the present invention may be adjusted in order, combined, or deleted as needed. The units in the system of the embodiment of the present invention may be combined, divided, or deleted as needed. In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit.
[0285] If this integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the existing technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, terminal, or network device, etc.) to execute all or part of the steps of the method described in various embodiments of the present invention.
[0286] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and such modifications or substitutions are intended to be within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.
Claims
1. An account limit increase management method based on account trusted authentication, characterized in that: include: Extract account information from the data warehouse, extract trust factors, and build a trustworthy account profile; Get account transaction data; Evaluate the account risk level based on the account trust file and the transaction data to obtain the account risk level; Determine a credit limit increase decision based on the account risk level to obtain a decision result; When the decision result is passed or manual service, the transaction data is input into the account trust rating model for trust level assessment to obtain the account trust level; Obtain account-related information; Calculate the account balance based on the account credibility level and the account-related information to obtain a calculation result; Output the account risk level and calculation results.
2. The account credit management method based on account trusted authentication according to claim 1 is characterized in that: The process of extracting account information from the data warehouse, extracting trust factors, and building a trustworthy account profile includes: Extract account information from the data warehouse, extract identification features of different trust factors, and assign a feature weight to each trust factor; Determine whether each of the trust factors meets the trust criteria based on the set identification strategy, filter the trust factors that meet the trust criteria and save them in the archive, and assign a trust weight score to obtain the account trust archive.
3. The account credit management method based on account trusted authentication according to claim 1 is characterized in that: The credibility factors include counterparty, transaction amount range, and transaction frequency.
4. The account credit management method based on account trusted authentication according to claim 1 is characterized in that: The trust weight score in the account trust profile gradually decays over time.
5. The account credit management method based on account trusted authentication according to claim 1 is characterized in that: The account credibility rating model is constructed by performing feature engineering on historical operation behavior and transaction flow data, identifying account credibility factors, and training the model using the GBDT integrated learning model.
6. The account credit increase management method based on account trusted authentication according to claim 5 is characterized in that: The training process of the account credibility rating model includes: Obtain historical operation behavior flow data and account transaction flow data to obtain a sample set; Preprocessing the sample set to obtain a first preprocessing result; Identifying account trust factors based on the first preprocessing result and generating corresponding trust features to obtain trust factor features; Build an integrated learning model based on GBDT; The trust factor features are input into the GBDT-based integrated learning model for training to obtain an account trust rating model.
7. The account credit increase management method based on account trusted authentication according to claim 6, characterized in that: The identifying of the account trust factor based on the first preprocessing result and generating a corresponding trust feature to obtain a trust factor feature includes: identifying account credibility factors based on the first preprocessing result to obtain basic features; Expanding and transforming the basic features to obtain expanded results; Feature selection is performed from the expanded results to obtain corresponding credible features, so as to obtain credible factor features.
8. The account credit management method based on account trusted authentication according to claim 1 is characterized in that: The assessment of the account risk level based on the account trustworthy file and the transaction data to obtain the account risk level includes: An account risk rating model is used to evaluate the account risk level to obtain the account risk level, wherein the account risk rating model is a model trained by using historical operation behavior flow data and dynamic account transaction flow data using the GBDT ensemble learning method.
9. The account credit management method based on account trust authentication according to claim 1 is characterized in that: The calculating of the account limit according to the account credibility level and the account-related information to obtain a calculation result includes: The account credibility level and the account-related information are input into the credit limit calculation matrix to calculate the account credit limit to obtain a calculation result; wherein, the account-related information includes the customer value level, the customer credit loan limit, the customer's AUM, the maximum value of the account's habitual daily transaction amount range in the account credibility file, and the bank's maximum non-counter limit.
10. An account credit management system based on account trusted authentication, characterized in that: include: A trusted profile building unit is used to extract account information from the data warehouse, extract trust factors, and build a trusted account profile; Behavior acquisition unit, used to obtain account transaction data; a risk assessment unit, configured to assess the account risk level based on the account trust file and the transaction data to obtain the account risk level; A decision-making unit, configured to determine a credit limit increase decision based on the account risk level to obtain a decision result; a trust evaluation unit configured to input the transaction data into an account trust rating model to perform a trust level evaluation to obtain an account trust level when the decision result is pass or manual service; An information acquisition unit, used to acquire account-related information; a calculation unit, configured to calculate the account limit based on the account trust level and the account-related information to obtain a calculation result; The output unit is used to output the account risk level and the calculation result.
Citation Information
Cited By
Quick withdrawal method and system for binding bank card to third-party payment platform
CN121526594A
