Financial institution risk account management and control method, device, equipment, program and medium
By constructing a complete set of risk management accounts and combining time retrospection and feature scanning mechanisms, the problems of data silos and passive lag in financial risk management have been solved, enabling accurate identification and real-time blocking of potential risks and improving the accuracy and timeliness of risk account management.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA CONSTRUCTION BANK
- Filing Date
- 2025-12-29
- Publication Date
- 2026-04-28
AI Technical Summary
Existing financial risk management technologies suffer from data silos, narrow risk identification perspectives, passivity and lag, and a lack of proactive risk discovery and real-time blocking capabilities. They also make it difficult to implement refined dynamic limit restrictions, leading to missed risk identifications or unintended consequences for normal customer transactions.
By acquiring a list of accounts involved in the case, a set of external risk accounts, and information on internal accounts, a comprehensive risk control account set is constructed. Combined with time retrospective and feature scanning mechanisms, the system accurately locates accounts associated with historically involved funds, proactively identifies accounts with abnormal behavior, and implements differentiated interception based on risk levels.
It significantly improves the coverage and depth of risk identification, enhances the accuracy and timeliness of risk account management, effectively solves the problems of single data sources, delayed identification, and false positive rate, and achieves accurate identification and real-time blocking of potential risks.
Smart Images
Figure CN121937196A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of financial risk management technology, specifically to a method, apparatus, equipment, procedure, and medium for managing risk accounts in financial institutions. Background Technology
[0002] Existing financial risk management technologies typically rely on independent risk control systems within each financial institution, primarily conducting single-point risk assessments based on static customer information, historical transaction records, and post-event audit reports. The lack of effective information sharing mechanisms between different institutions leads to severe data silos, making it difficult to capture the full picture of cross-institutional fund flows, resulting in a narrow and one-sided risk identification perspective. Furthermore, traditional control methods are often significantly passive and lagging, typically requiring regulatory authorities to issue a clear list of involved parties or receive customer complaints before freezing assets, lacking the ability to proactively uncover potential hidden risks and the ability to block transactions in real time. Simultaneously, existing technologies often employ a "black and white" broad-based control strategy, making it difficult to implement refined dynamic limits based on risk levels. This often leads to missed risk identifications or unintended consequences for legitimate customers when facing rapidly evolving fraudulent methods, failing to meet the increasingly complex anti-fraud risk control needs. Summary of the Invention
[0003] The purpose of this application is to provide a method, apparatus, device, program, and medium for risk account management in financial institutions, in order to solve the problem of low accuracy in risk account management in the prior art.
[0004] To achieve the above objectives, the first aspect of this application provides a method for managing risk accounts in financial institutions, the method comprising: Obtain the list of accounts involved in the case, the set of external risky accounts, all internal account information of the target financial institution, and the set of verified reported accounts; The internal risk account set of the target financial institution is determined based on the list of accounts involved, the preset tracing period, the preset risk amount threshold, the preset risk feature set, and all internal account information of the target financial institution. The internal risk account set and the external risk account set are merged into a full risk management account set; In response to a user's transaction request, the user's account information and transaction amount are parsed from the transaction request; The system determines whether to execute a transaction request based on the user's account information, the full set of risk-controlled accounts, the transaction amount, and the preset transaction limit library.
[0005] In this embodiment of the application, the step of determining the internal risk account set of the target financial institution based on the list of accounts involved in the case, the preset tracing period, the preset risk amount threshold, the preset risk feature set, and all internal account information of the target financial institution includes: determining a first risk account set based on the list of accounts involved in the case, the preset tracing period, and the preset risk amount threshold; scanning all internal account information of the target financial institution based on the preset risk feature set to output a second risk account set; and performing data cleaning and aggregation on the reported account set, the first risk account set, and the second risk account set to output an internal risk account set.
[0006] In this embodiment of the application, the step of determining the first risk account set based on the list of accounts involved in the case, the preset tracing duration, and the preset risk amount threshold includes: extracting multiple accounts involved in the case and the control start time corresponding to each account involved in the case from the list of accounts involved in the case; determining the traceability transaction details of each account involved in the case based on the control start time corresponding to each account involved in the case and the preset tracing duration; determining whether the corresponding account involved in the case is a first risk account based on the transaction amount in the traceability transaction details and the preset risk amount threshold; and filling the first risk account into the first risk account set.
[0007] In this embodiment, the preset risk feature set includes small-amount trial transaction features and end-of-day cleared account features; each internal account information includes the internal account holder and the corresponding risk feature; the step of scanning all internal account information of the target financial institution according to the preset risk feature set and outputting the second risk account set includes: matching the risk features in each internal account information with the small-amount trial transaction features and / or end-of-day cleared account features; if the match is successful, the corresponding internal account holder is taken as the second risk account, and the second risk account is filled into the second risk account set.
[0008] In this embodiment, the full risk control account set includes multiple risk control accounts and a risk level corresponding to each risk control account. The steps of determining whether to execute a transaction request based on the user's account information, the full risk control account set, the transaction amount, and a preset transaction limit library include: matching the user's account information with multiple risk control accounts; if a match is successful, using the risk level corresponding to the risk control account as the risk level corresponding to the user's account information, and determining the maximum allowed transaction amount for the transaction request based on the risk level and the preset transaction limit library; the preset transaction limit library stores the mapping relationship between risk levels and the maximum allowed transaction amount; and executing the transaction request if the transaction amount is less than or equal to the maximum allowed transaction amount.
[0009] In this embodiment of the application, the method further includes: blocking the transaction request and issuing an alarm for the transaction request if the transaction amount exceeds the allowed transaction amount limit.
[0010] A second aspect of this application provides a risk account management device for financial institutions, comprising: an acquisition module for acquiring a list of accounts involved in a case and a set of external risk accounts, all internal account information of the target financial institution, and a set of verified reported accounts; a determination module for determining the internal risk account set of the target financial institution based on the list of accounts involved in the case, a preset tracing duration, a preset risk amount threshold, a preset risk feature set, and all internal account information of the target financial institution; a merging module for merging the internal risk account set and the external risk account set into a full risk management account set; a parsing module for parsing the user's account information and transaction amount from the transaction request in response to a user's transaction request; and an execution module for determining whether to execute the transaction request based on the user's account information, the full risk management account set, the transaction amount, and a preset transaction limit library.
[0011] A third aspect of this application provides a computer device, comprising: The memory is configured to store instructions; and The processor is configured to retrieve instructions from memory and to implement the methods described above when executing instructions.
[0012] A fourth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0013] A fifth aspect of this application provides a machine-readable storage medium storing instructions that cause a machine to perform the methods described above.
[0014] The aforementioned technical solutions can aggregate multi-dimensional data sources, including lists of involved parties, external industry intelligence, internal full-volume data, and social whistleblowing information, breaking down data silos and information barriers between financial institutions. Utilizing a dual identification mechanism combining time retrospection and feature scanning, it can accurately locate related accounts of historically involved funds and proactively uncover accounts with potential abnormal behavior, significantly improving the coverage and depth of risk identification. Simultaneously, by constructing a full set of risk-controlled accounts and responding to real-time transaction requests, the risk control checkpoint is moved forward to the moment a transaction occurs. Differential interception is implemented based on the dynamic mapping relationship between risk level and a preset transaction limit database, effectively solving problems such as single data sources, delayed risk identification, and high false positive rates in existing technologies. This significantly improves the accuracy and timeliness of banks' management of fraud-related risk accounts.
[0015] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description
[0016] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings: Figure 1 A flowchart illustrating a risk account management method for a financial institution according to an embodiment of this application is shown schematically. Figure 2 This schematic diagram illustrates a structural diagram of a risk account management device for a financial institution according to an embodiment of this application; Figure 3 The schematic diagram illustrates a structural diagram of a computer device according to an embodiment of this application. Detailed Implementation
[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0018] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.
[0019] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.
[0020] The acquisition, transmission, storage, use, and processing of data in this application comply with relevant laws and regulations. Furthermore, it should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.
[0021] It should be noted that the customer information (including but not limited to the list of accounts involved in the case, the set of external risk accounts, internal account information, the set of reported accounts, etc.) and various data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the customer or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0022] Figure 1 A flowchart illustrating a risk account management method for a financial institution according to an embodiment of this application is shown schematically. Figure 1 As shown in the figure, this application provides a method for risk account management in financial institutions, which may include the following steps.
[0023] Step 101: Obtain the list of accounts involved in the case, the set of external risky accounts, all internal account information of the target financial institution, and the set of verified reported accounts.
[0024] In this embodiment, the list of accounts involved in the case can refer to a list of accounts confirmed to be involved in illegal or irregular activities, published by an authorized agency, typically including the accounts involved and the time information of the control measures taken against them. The external risk account set refers to high-risk account data identified and reported by other financial institutions, industry sharing platforms, or third-party risk control systems outside the target financial institution, reflecting cross-institutional risk intelligence. The target financial institution refers to the specific implementing entity that executes the risk control method, such as a commercial bank or non-bank payment institution. All internal account information covers all dimensions of data, including the basic profile of the account holder, historical transaction details, and current account status stored locally by the target financial institution. The verified set of reported accounts refers to the set of accounts to be investigated based on complaints and reports from customers or other external entities, after verification of authenticity (such as verification of police report receipts) and exclusion of interference factors such as disputes or malicious reports. By aggregating authoritative lists from authorized agencies, shared intelligence from peer institutions, full-volume data within the institution, and cleaned and verified social whistleblowing information, the limitations and biases of a single data source are overcome. This multi-dimensional and broad-domain data collection strategy provides more comprehensive and high-quality data input for subsequent risk feature scanning and correlation analysis, thereby effectively avoiding missed or misjudgments due to missing information and improving the accuracy of risk account management from the data source.
[0025] Step 102: Determine the set of internal risk accounts of the target financial institution based on the list of accounts involved, the preset tracing period, the preset risk amount threshold, the preset risk feature set, and all internal account information of the target financial institution.
[0026] In this embodiment, the preset tracing duration refers to the time span set by the system for tracing historical transaction data. It is used to define a specific time window before control measures are taken against the involved accounts, allowing for the investigation of fund flows within that window. The preset risk amount threshold is a standard for the amount of funds set to screen abnormal transactions. It filters out normal living expenses or low-risk transactions below this amount during the investigation process, focusing on large suspicious fund flows. The preset risk feature set is a set of logical rules built based on historical risk data and expert experience to identify abnormal account usage patterns. It covers typical fraudulent or money laundering behavior models such as rapid fund inflows and outflows, small trial transactions, or daily account balance clearing. The internal risk account set refers to the set of accounts belonging to the target financial institution and possessing high potential risk, ultimately determined after filtering and calculating massive amounts of data using the above parameters and rules. On the one hand, by using the preset tracing duration and preset risk amount threshold, hidden accounts with strong financial connections to known involved accounts are accurately located. On the other hand, the preset risk feature set proactively discovers accounts that are not yet on the list but exhibit abnormal behavior. This effectively eliminates transaction interference that is part of normal production and business operations, ensuring the depth and breadth of risk identification and significantly improving the accuracy of risk account management.
[0027] Step 103: Merge the internal risk account set and the external risk account set into a full risk management account set.
[0028] Step 104: In response to the user's transaction request, parse the user's account information and transaction amount from the transaction request.
[0029] In this embodiment, the full-volume risk management account set refers to a unified management list database formed by aggregating, integrating, and deduplicating risk targets identified by the institution based on internal data and risk targets obtained from external channels. It represents a complete view of potential risk accounts currently held by the target financial institution. A transaction request refers to a data packet containing an instruction indicating the intention to transfer funds or conduct business, initiated by a user through channels such as bank counters, online banking, or mobile terminals. The user's account information refers to key identity elements, such as bank account number, payment token, or customer index number, parsed from the aforementioned instruction data packet to uniquely identify the transaction initiator. The transaction amount refers to the specific amount of funds to be transferred or paid in this instruction. Firstly, by constructing a full-volume view, monitoring blind spots caused by information fragmentation are eliminated. Then, by real-time parsing of transaction instructions, static risk data is correlated with dynamic business scenarios, ensuring that subsequent management judgments are based on the most comprehensive and real-time information foundation, thereby effectively improving the accuracy of risk account management.
[0030] Step 105: Determine whether to execute the transaction request based on the user's account information, the full set of risk control accounts, the transaction amount, and the preset transaction limit library.
[0031] In this embodiment, the preset transaction limit library refers to a set of strategy data stored in the system that defines the mapping relationship between different risk levels and corresponding allowed transaction amount limits. This set sets graded and categorized fund transfer threshold standards based on the severity of risk. By comparing the current transaction request elements with the full set of risk-controlled accounts and dynamically adapting the corresponding transaction limit restrictions in conjunction with the preset transaction limit library, differentiated handling based on risk level is achieved. This mechanism can accurately distinguish accounts with different levels of risk and apply matching control measures, blocking high-risk transactions while avoiding unnecessary damage to low-risk businesses, thereby significantly improving the accuracy of risk account management.
[0032] The aforementioned technical solutions can aggregate multi-dimensional data sources, including lists of involved parties, external industry intelligence, internal full-volume data, and social whistleblowing information, breaking down data silos and information barriers between financial institutions. Utilizing a dual identification mechanism combining time retrospection and feature scanning, it can accurately locate related accounts of historically involved funds and proactively uncover accounts with potential abnormal behavior, significantly improving the coverage and depth of risk identification. Simultaneously, by constructing a full set of risk-controlled accounts and responding to real-time transaction requests, the risk control checkpoint is moved forward to the moment a transaction occurs. Differential interception is implemented based on the dynamic mapping relationship between risk level and a preset transaction limit database, effectively solving problems such as single data sources, delayed risk identification, and high false positive rates in existing technologies. This significantly improves the accuracy and timeliness of banks' management of fraud-related risk accounts.
[0033] In this embodiment of the application, the step of determining the internal risk account set of the target financial institution based on the list of accounts involved in the case, the preset tracing period, the preset risk amount threshold, the preset risk feature set, and all internal account information of the target financial institution includes: determining a first risk account set based on the list of accounts involved in the case, the preset tracing period, and the preset risk amount threshold; scanning all internal account information of the target financial institution based on the preset risk feature set to output a second risk account set; and performing data cleaning and aggregation on the reported account set, the first risk account set, and the second risk account set to output an internal risk account set.
[0034] In this embodiment, the first risk account set refers to a subset of accounts determined based on fund flow correlation analysis. This subset, filtered by tracing the transaction links of the accounts involved within a specific time window and combining them with monetary standards, reflects potential risk objects with financial dealings with known risk sources. The second risk account set refers to a subset of abnormal accounts output after scanning all accounts according to preset behavioral pattern rules. This subset reflects high-risk objects with abnormal transaction characteristics. Data cleaning and aggregation refers to the integration process of standardizing the format, removing duplicates, and logically verifying multiple types of risk account data from different sources. By constructing a multi-dimensional risk identification funnel, the first risk account set accurately captures the related nodes in the fund chain involved in the case. The second risk account set proactively uncovers hidden targets with abnormal behavioral characteristics. Finally, it deeply integrates multi-source data covering fund-related, abnormal behavior, and reported categories. This mechanism can comprehensively cover potential risks from both passive tracing and proactive discovery perspectives, and eliminates data noise through standardization processing, thereby significantly improving the accuracy of risk account management.
[0035] In one embodiment, the internal risk account set may further include corporate bank accounts identified by authorized authorities deployed by the financial institution through a corporate banking model, and which have been subject to strict risk control measures such as restricting non-counter transactions, allowing only receipts and no payments, or no receipts and no payments at all. After determining the internal risk account set, it may also be shared with other financial institutions.
[0036] In this embodiment of the application, the step of determining the first risk account set based on the list of accounts involved in the case, the preset tracing duration, and the preset risk amount threshold includes: extracting multiple accounts involved in the case and the control start time corresponding to each account involved in the case from the list of accounts involved in the case; determining the traceability transaction details of each account involved in the case based on the control start time corresponding to each account involved in the case and the preset tracing duration; determining whether the corresponding account involved in the case is a first risk account based on the transaction amount in the traceability transaction details and the preset risk amount threshold; and filling the first risk account into the first risk account set.
[0037] In this embodiment, the "account involved in the case" refers to a single specific fund account entity parsed from the list of accounts involved in the case, serving as the source node for risk transmission. The control start time can refer to the specific point in time when the account is formally subject to restrictive measures such as payment suspension or freezing by the competent authority or risk control system, marking the establishment of the account's risk status. The traceable transaction details refer to the historical fund flow records of the account, including transaction direction, transaction amount, and counterparty information, within a time window calculated backwards or forwards from the control start time as a baseline and within a preset traceability period. The first-risk account refers to a specific account object that, through the aforementioned time and amount logic verification, is determined to meet the characteristics of high-risk fund transfers and needs to be included in key control. By introducing a refined backtracking mechanism with a time dimension, the high-risk activity window of the account involved in the case before being controlled is accurately locked using the control start time and preset traceability period. Combined with the dual verification of transaction amount, redundant data that is irrelevant in time or lacks risk characteristics in terms of amount is effectively eliminated. This ensures that each first-risk account entered into the first-risk account set has undergone rigorous logical verification, thereby significantly improving the accuracy of risk account control.
[0038] In this embodiment, the preset risk feature set includes small-amount trial transaction features and end-of-day cleared account features; each internal account information includes the internal account holder and the corresponding risk feature; the step of scanning all internal account information of the target financial institution according to the preset risk feature set and outputting the second risk account set includes: matching the risk features in each internal account information with the small-amount trial transaction features and / or end-of-day cleared account features; if the match is successful, the corresponding internal account holder is taken as the second risk account, and the second risk account is filled into the second risk account set.
[0039] In this application embodiment, the small-amount trial transaction characteristic refers to a pattern of small-amount fund inflows and outflows that occur before a large-amount fund transfer, used to verify the validity of the account or the smooth operation of the channel. It usually serves as a preliminary trial signal for illegal fund transfers. The end-of-day zeroing account characteristic refers to a pattern of fund bridging behavior in which account funds are quickly in and out, and are immediately settled, with the balance approaching zero at the end of the day or at the end of a specific period. This reflects the typical attribute of money laundering accounts that do not retain funds. The internal account subject refers to the specific customer object or unique account identifier that has opened an account in the core system of a financial institution, and is the ultimate point of application for risk control measures. Risk characteristics refer to attribute data extracted from the account's historical transaction data, login logs, or operational behavior that can digitally represent the account's usage habits and status. By transforming abstract expert risk control experience into quantifiable and computable feature matching logic, an automated full-scale scan of massive existing accounts is achieved. The system can accurately identify hidden accounts that, although not on external lists, have shown obvious fraudulent or money laundering patterns, thus enabling proactive discovery and locking before risks materialize. This effectively compensates for the lag in passive list defense and significantly improves the accuracy of risk account management.
[0040] In this embodiment, the full risk control account set includes multiple risk control accounts and a risk level corresponding to each risk control account. The steps of determining whether to execute a transaction request based on the user's account information, the full risk control account set, the transaction amount, and a preset transaction limit library include: matching the user's account information with multiple risk control accounts; if a match is successful, using the risk level corresponding to the risk control account as the risk level corresponding to the user's account information, and determining the maximum allowed transaction amount for the transaction request based on the risk level and the preset transaction limit library; the preset transaction limit library stores the mapping relationship between risk levels and the maximum allowed transaction amount; and executing the transaction request if the transaction amount is less than or equal to the maximum allowed transaction amount.
[0041] In this embodiment, a risk control account refers to each specific unit of the target object included in the entire risk control account set, which is associated with specific risk attributes. A risk level is a quantitative rating or classification identifier for each target object based on the severity of the case, the closeness of the financial connection, or the degree of behavioral abnormality, used to distinguish different risk levels. The maximum allowed transaction amount refers to the highest threshold of funds authorized by the system for a single transaction or within a specific period, dynamically calculated based on the current risk level. By establishing a multi-level mapping mechanism from account identity to risk level, and then from risk level to specific amount thresholds, refined risk control is achieved. The system no longer simply uses blacklists and whitelists for blanket blocking, but dynamically adapts differentiated transaction limits according to the actual risk level of the account. While ensuring effective blocking of high-risk fund flows exceeding security thresholds, it allows normal transactions within compliant limits, thus finding the optimal balance between ensuring fund security and maintaining business continuity, significantly improving the accuracy of risk account control.
[0042] In one embodiment, a user's account information is matched with multiple risk-controlled accounts. If a match is successful, the corresponding account information can be used for risk screening, and the screening results can be applied to the corresponding user's subsequent financial activities at the financial institution, including but not limited to account opening, loan and transfer limits.
[0043] In this embodiment of the application, the method further includes: blocking the transaction request and issuing an alarm for the transaction request if the transaction amount exceeds the allowed transaction amount limit.
[0044] Through the above technical solution, firstly, at the data source level of risk identification, by integrating authoritative lists of involved accounts, industry-shared external risk account sets, and verified sets of reported accounts, the system breaks through the data limitations of a single financial institution, providing a comprehensive data foundation for subsequent accurate calculations. Secondly, at the logical reasoning level of internal risk mining, it does not stop at simple list matching, but adopts a dual reasoning mechanism: one is reasoning based on the backtracking of fund flows, that is, using the start time of control to deduce the preset tracing period, and within the time window before the involved accounts are blocked, combined with preset risk amount thresholds, accurately locate the flow of funds, thereby uncovering the hidden first set of risk accounts; the other is reasoning based on behavioral pattern characteristics, by scanning typical money laundering characteristics such as small-amount trial transactions and end-of-day clearing, proactively identifying a second set of risk accounts that have not yet been included in the list but exhibit abnormal behavior. This mechanism makes potential risks explicit through logical calculations, significantly reducing the false negative rate. Furthermore, at the level of constructing a comprehensive risk overview, by merging the cleaned and aggregated internal risk account set with the external risk account set into a full-scale risk management account set, it achieves a leap from localized defense to comprehensive joint defense, ensuring the integrity of the management list. Finally, at the level of transaction execution judgment, the solution abandons the traditional black-and-white, one-size-fits-all blocking model, instead establishing a dynamic mapping logic of "risk level - transaction limit." When the system responds to a transaction request, it analyzes account information in real time and matches the risk level, then retrieves the corresponding allowed upper limit from a preset transaction limit library. Blocking and alarms are only triggered when the transaction amount exceeds this limit. This differentiated control method based on quantitative thresholds can effectively intercept high-risk funds at critical moments while minimizing interference with low-risk misjudged transactions, thus significantly improving the accuracy and scientific nature of risk management while ensuring fund security.
[0045] Figure 2 This diagram schematically illustrates a structural diagram of a risk account management device for a financial institution according to an embodiment of this application. Figure 2As shown in the illustration, this application embodiment also provides a risk account management device for financial institutions, including: an acquisition module 210, used to acquire a list of accounts involved in a case and an external risk account set, all internal account information of the target financial institution, and a verified set of reported accounts; a determination module 220, used to determine the internal risk account set of the target financial institution based on the list of accounts involved in the case, a preset tracing duration, a preset risk amount threshold, a preset risk feature set, and all internal account information of the target financial institution; a merging module 230, used to merge the internal risk account set and the external risk account set into a full risk management account set; a parsing module 240, used to parse the user's account information and transaction amount from the transaction request in response to a user-initiated transaction request; and an execution module 250, used to determine whether to execute the transaction request based on the user's account information, the full risk management account set, the transaction amount, and a preset transaction limit library.
[0046] Figure 3 A schematic diagram illustrating the structure of a computer device according to an embodiment of this application is provided. Figure 3 As shown, this application provides a computer device that may include: Memory 310 is configured to store instructions; and Processor 320 is configured to retrieve instructions from memory 310 and to implement the methods described above when executing instructions.
[0047] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0048] This application also provides a machine-readable storage medium storing instructions that cause a machine to perform the above-described method.
[0049] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0050] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0051] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0052] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0053] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0054] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0055] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0056] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0057] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A method for managing risk accounts in financial institutions, characterized in that, The method includes: Obtain the list of accounts involved in the case, the set of external risky accounts, all internal account information of the target financial institution, and the set of verified reported accounts; The internal risk account set of the target financial institution is determined based on the list of accounts involved in the case, the preset tracing duration, the preset risk amount threshold, the preset risk feature set, and all internal account information of the target financial institution. The internal risk account set and the external risk account set are merged into a full risk management account set; In response to a transaction request initiated by a user, the user's account information and transaction amount are parsed from the transaction request; The system determines whether to execute the transaction request based on the user's account information, the full set of risk-controlled accounts, the transaction amount, and the preset transaction limit library.
2. The method according to claim 1, characterized in that, The step of determining the internal risk account set of the target financial institution based on the list of accounts involved in the case, the preset tracing duration, the preset risk amount threshold, the preset risk feature set, and all internal account information of the target financial institution includes: The first risk account set is determined based on the aforementioned list of accounts involved in the case, the preset tracing duration, and the preset risk amount threshold. Based on a preset risk feature set, all internal account information of the target financial institution is scanned, and a second risk account set is output. The reported account set, the first risk account set, and the second risk account set are cleaned and aggregated to output the internal risk account set.
3. The method according to claim 2, characterized in that, The step of determining the first risk account set based on the list of accounts involved in the case, the preset tracing duration, and the preset risk amount threshold includes: Extract multiple accounts involved in the case and the control start time corresponding to each account from the list of accounts involved in the case; The traceability transaction details for each account involved in the case are determined based on the control start time and preset traceability duration corresponding to each account involved in the case. Based on the transaction amount in the traceable transaction details and the preset risk amount threshold, it is determined whether the corresponding account involved in the case is a first-risk account; Populate the first risk account into the first risk account set.
4. The method according to claim 2, characterized in that, The preset risk feature set includes small-amount trial transaction features and end-of-day cleared account features; each internal account information includes the internal account entity and the corresponding risk features; The step of scanning all internal account information of the target financial institution according to a preset risk feature set and outputting a second risk account set includes: Match the risk characteristics in each internal account information with the small-amount trial transaction characteristics and / or the end-of-day cleared account characteristics; If a match is found, the corresponding internal account entity will be designated as the second risk account, and the second risk account will be added to the second risk account set.
5. The method according to any one of claims 1 to 4, characterized in that, The full set of risk management accounts includes multiple risk management accounts and the risk level corresponding to each risk management account; The step of determining whether to execute the transaction request based on the user's account information, the full set of risk-controlled accounts, the transaction amount, and the preset transaction limit library includes: Match the user's account information with the multiple risk control accounts; If a match is successful, the risk level corresponding to the risk management account will be used as the risk level corresponding to the user's account information, and the maximum allowed transaction amount for the transaction request will be determined based on the risk level and the preset transaction limit library; the preset transaction limit library stores the mapping relationship between risk levels and maximum allowed transaction amounts. The transaction request is executed if the transaction amount is less than or equal to the maximum allowed transaction amount.
6. The method according to claim 5, characterized in that, The method further includes: If the transaction amount exceeds the allowed transaction amount limit, the transaction request will be blocked and an alarm will be issued for the transaction request.
7. A risk account management device for financial institutions, characterized in that, include: The acquisition module is used to acquire the list of accounts involved in the case, the set of external risky accounts, all internal account information of the target financial institution, and the set of verified reported accounts; The determination module is used to determine the internal risk account set of the target financial institution based on the list of accounts involved in the case, the preset tracing duration, the preset risk amount threshold, the preset risk feature set, and all internal account information of the target financial institution. The merging module is used to merge the internal risk account set and the external risk account set into a full risk management account set; The parsing module is used to respond to a transaction request initiated by a user and parse the user's account information and transaction amount from the transaction request; The execution module is used to determine whether to execute the transaction request based on the user's account information, the full set of risk control accounts, the transaction amount, and the preset transaction limit library.
8. A computer device, characterized in that, include: The memory is configured to store instructions; as well as A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the method according to any one of claims 1 to 6.
9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 6.
10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to perform the method according to any one of claims 1 to 6.