Risk decision early warning method and device, equipment and storage medium
By extracting and reconstructing decision conclusion information, generating and comparing benchmark values, the problems of complex risk decision-making process and low monitoring and early warning allocation in loan review are solved, and efficient and accurate early warning of risk decision-making is achieved.
Patent Information
- Application Number
- CN202411522495.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-29
- Publication Date
- 2025-03-25
AI Technical Summary
When financial institutions conduct loan reviews, the risk decision-making process is complex, and the decision-making conclusion information needs to be updated frequently, which leads to low efficiency in monitoring and early warning allocation, prone to errors, and difficult to detect abnormal decision-making conclusions.
By extracting and refactoring the decision conclusion information based on predefined annotations, the formatted monitoring fields are obtained and stored in the decision conclusion ES cluster. Based on the decision conclusion, the historical data of the ES cluster is generated, and the warning conditions are compared in real time and the warning conditions are triggered, and stored in the warning ES cluster for abnormal checks and locations.
It realizes automated monitoring, improves the accuracy and efficiency of monitoring, reduces false alarms and missed reports, improves the reliability and practicality of early warnings, shortens the processing time of abnormal data, and improves the efficiency of abnormal troubleshooting.
Smart Images
Figure CN119692753A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of electronic digital data processing, and in particular to risk decision warning methods, devices, equipment and storage media. Background Art
[0002] As the financial market becomes increasingly complex and diversified, financial institutions need to consider more and more risk factors when conducting loan reviews, including but not limited to the borrower's credit history, income level, repayment ability, collateral value, etc. This makes the risk decision-making process more complicated, and the decision conclusion information needs to be frequently updated to adapt to the ever-changing credit approval risk requirements.
[0003] Financial institutions usually evaluate whether the decision service is operating normally by observing the basic elements of the decision conclusions such as the overall approval rate, quota, interest rate, etc. However, this approach has obvious limitations. For example, for some important fields that affect the business process, such as whether electronic review is required and whether it needs to be offline, it is difficult to accurately reflect their status only through indicators such as the overall pass rate. When the decision conclusion returns abnormally and requires electronic review, it will significantly increase the workload of the electronic review department and affect the overall business efficiency.
[0004] In addition, decision-making services and monitoring and early warning services often exist as two independent functional services. When a new decision conclusion element is added to the decision-making service, the monitoring and early warning service needs to be modified accordingly to ensure the accuracy of the early warning. This process is not only cumbersome, but also prone to human errors. At the same time, when the decision conclusion is abnormal, it takes a long time to locate the detailed data and conduct abnormality troubleshooting, which further prolongs the time for problem handling and reduces the efficiency of business operations. Summary of the invention
[0005] The main purpose of this application is to provide a risk decision warning method, device, equipment and storage medium, aiming to solve the technical problems of low efficiency and easy errors in monitoring warning configuration and difficulty in troubleshooting abnormal decision conclusions.
[0006] To achieve the above purpose, the present application provides a risk decision early warning method, which includes the following steps:
[0007] Extract and reconstruct the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and store the formatted monitoring fields in the decision conclusion ES cluster, where the decision conclusion information is risk decision conclusion data obtained in advance through the decision service;
[0008] Generate a benchmark value based on the historical data of the ES cluster based on the decision conclusion;
[0009] The real-time conclusion information in the decision conclusion ES cluster is compared with the reference value. If the comparison result triggers the preset warning condition, the generated warning detail data is stored in the warning ES cluster;
[0010] The abnormality detail data corresponding to the early warning summary data is generated by the early warning ES cluster, and the abnormality is checked and located according to the abnormality detail data. The early warning summary data is obtained through the front-end input.
[0011] In one embodiment, the step of extracting and reconstructing the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and storing the formatted monitoring fields in a decision conclusion ES cluster, wherein the decision conclusion information is risk decision conclusion data obtained in advance through a decision service, includes:
[0012] By parsing the predefined annotations of decision conclusion information, the decision conclusion fields that need to be monitored are extracted;
[0013] Reconstruct the monitoring field name of the decision conclusion field according to a preset format to obtain a formatted monitoring field;
[0014] Asynchronously sending the formatted monitoring fields encapsulated into Kafka messages to the decision conclusion Kafka topic;
[0015] The formatted monitoring fields are extracted from the decision conclusion Kafka topic and written into the decision conclusion ES cluster.
[0016] In one embodiment, the step of generating a benchmark value based on the historical data of the decision conclusion ES cluster includes:
[0017] Based on the historical data of the ES cluster of the decision conclusion, the benchmark value is generated according to the numerical value, code value and custom type.
[0018] In one embodiment, the step of comparing the real-time conclusion information in the decision conclusion ES cluster with the benchmark value, and if the comparison result triggers a preset warning condition, storing the triggered warning detail data into the warning ES cluster includes:
[0019] Compare the real-time conclusion information in the decision conclusion ES cluster with the benchmark value, and determine whether the comparison result triggers an early warning according to the preset early warning condition;
[0020] If an alert is triggered, the alert details generated by the trigger will be asynchronously sent to the alert Kafka topic;
[0021] The warning detail data is extracted from the warning Kafka topic, and the warning detail data is written into the warning ES cluster.
[0022] In one embodiment, the step of comparing the real-time conclusion information in the decision conclusion ES cluster with the benchmark value, and if the comparison result triggers a preset warning condition, storing the triggered warning detail data in the warning ES cluster before the step further includes:
[0023] By configuring scheduled tasks, you can obtain real-time conclusion information of the ES cluster.
[0024] In one embodiment, the step of generating abnormality detail data corresponding to the early warning summary data through the early warning ES cluster, performing abnormality investigation and positioning according to the abnormality detail data, and obtaining the early warning summary data through the front-end input includes:
[0025] Get the warning summary data input by the front end;
[0026] According to the warning summary data, a query operation is performed in the warning ES cluster to obtain a query result;
[0027] Extracting abnormality detail data corresponding to the early warning summary data from the query result;
[0028] Anomalies are checked and located based on the analysis results of the abnormal detailed data.
[0029] In one embodiment, the step of extracting and reconstructing the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and storing the formatted monitoring fields in the decision conclusion ES cluster, wherein the decision conclusion information is risk decision conclusion data obtained in advance through the decision service, further includes:
[0030] Perform risk assessment based on input risk assessment data to generate decision conclusion information;
[0031] The information that needs to be monitored in the decision conclusion information is marked by predefined annotations.
[0032] In addition, to achieve the above purpose, the present application also provides a risk decision warning device, the risk decision warning device comprising:
[0033] The pre-order module is used to extract and reconstruct the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and store the formatted monitoring fields in the decision conclusion ES cluster. The decision conclusion information is the risk decision conclusion data obtained in advance through the decision service;
[0034] A benchmark value generation module, used to generate a benchmark value based on the historical data of the decision conclusion ES cluster;
[0035] A monitoring and early warning module is used to compare the real-time conclusion information in the decision conclusion ES cluster with the benchmark value. If the comparison result triggers a preset early warning condition, the triggered early warning detail data is stored in the early warning ES cluster;
[0036] The abnormality investigation module is used to generate abnormality detail data corresponding to the early warning summary data through the early warning ES cluster, and perform abnormality investigation and positioning according to the abnormality detail data. The early warning summary data is obtained through front-end input.
[0037] In addition, to achieve the above-mentioned purpose, the present application also provides a terminal device, which includes a memory, a processor, and a risk decision warning program stored in the memory and executable on the processor, and the risk decision warning program, when executed by the processor, implements the steps of the risk decision warning method described above.
[0038] In addition, to achieve the above-mentioned purpose, the present application also provides a computer-readable storage medium, on which a risk decision warning program is stored. When the risk decision warning program is executed by a processor, the steps of the risk decision warning method described above are implemented.
[0039] One or more technical solutions proposed in this application have at least the following technical effects:
[0040] Due to the adoption of extracting and reconstructing the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and storing the formatted monitoring fields in the decision conclusion ES cluster, the decision conclusion information is the risk decision conclusion data obtained in advance through the decision service, and the benchmark value is generated based on the historical data of the decision conclusion ES cluster, and then the real-time conclusion information in the decision conclusion ES cluster is compared with the benchmark value. If the preset warning condition is triggered, the triggered warning detail data is stored in the warning ES cluster. Finally, the abnormal detail data corresponding to the input warning summary data is generated by querying the warning ES cluster, and the technical means of abnormal investigation and positioning are performed according to the abnormal detail data, which solves the technical problems of low efficiency and easy error in monitoring warning configuration and difficulty in abnormal investigation of decision conclusions. Compared with the prior art, the present application realizes comprehensive coverage of automated monitoring and improves the accuracy and efficiency of monitoring. At the same time, differentiated warnings are performed for different field types, reducing false positives and missed positives, and improving the reliability and practicality of warnings.
[0041] In addition, by asynchronously sending decision conclusion information to the Kafka topic and storing it in the ES cluster, real-time data collection and efficient storage are achieved. Benchmark values are generated based on the historical data of the ES cluster and compared with the real-time conclusion information to detect abnormal situations in a timely manner. Once the preset warning conditions are triggered, the warning details will be automatically stored in the warning ES cluster for subsequent query and analysis. This technical solution not only shortens the processing time of abnormal data, but also quickly locates the details of abnormal data through the warning summary information, making problem troubleshooting more efficient and accurate. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] Figure 1 This is a flow chart of the first exemplary embodiment of the risk decision-making early warning method of this application;
[0043] Figure 2 This is a flow chart of the second exemplary embodiment of the risk decision warning method of this application;
[0044] Figure 3 This is a flow chart of the third exemplary embodiment of the risk decision warning method of this application;
[0045] Figure 4 This is a schematic diagram of the module structure of the risk decision-making and early warning device of the embodiment of the present application;
[0046] Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the risk decision warning method in the embodiment of the present application.
[0047] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION
[0048] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0049] The main solution of the embodiment of the present application is: extract and reconstruct the decision conclusion information based on the predefined annotation to obtain the formatted monitoring field, and store the formatted monitoring field in the decision conclusion ES cluster, the decision conclusion information is the risk decision conclusion data obtained in advance through the decision service; generate a benchmark value based on the historical data of the decision conclusion ES cluster; compare the real-time conclusion information in the decision conclusion ES cluster with the benchmark value, if the comparison result triggers the preset warning condition, then store the triggered warning detail data in the warning ES cluster; generate the abnormal detail data corresponding to the warning summary data through the warning ES cluster, and perform abnormal investigation and positioning according to the abnormal detail data, and the warning summary data is obtained through the front-end input. Compared with the prior art, the decision service and the monitoring and warning service are two independent functional modules, which leads to the need to manually modify the monitoring and warning service when adding new decision conclusion elements, and the abnormal investigation is time-consuming and inefficient. The present application realizes the automatic collection of decision conclusion monitoring fields, identification of field types and automatic inclusion in monitoring, and rapid positioning of abnormal data details through warning summary information, thereby significantly improving the efficiency of abnormal investigation and ensuring the accuracy of risk decision conclusions.
[0050] Technical terms involved in the embodiments of this application:
[0051] ES (Elasticsearch): is a search engine based on Lucene. It provides a distributed multi-user full-text search engine with an HTTP web interface and a schema-less JSON document. An ES cluster consists of multiple nodes that work together to store and retrieve data. Each node is an Elasticsearch instance that can store data and participate in indexing and search functions. In this application, after the decision service sends the risk decision conclusion information asynchronously to the decision conclusion Kafka topic in the style of annotations, this information will be stored in the decision conclusion ES cluster. Therefore, all decision conclusion information is centrally stored and managed to facilitate subsequent analysis and processing.
[0052] Kafka: is a distributed stream processing platform that can publish and subscribe to record streams, similar to an enterprise-level messaging system. In this application, Kafka is mainly used to implement asynchronous data transmission. The decision service sends the risk decision conclusion information to the decision conclusion Kafka topic asynchronously in the style of annotations. The Kafka topic is used as a message queue to receive and store decision conclusion information from the decision service. These messages are sent asynchronously, which means that they will not block the execution of the decision service, thereby improving the throughput and responsiveness of the system.
[0053] The executor of the method of this embodiment can be a risk decision warning device, or a risk decision warning terminal device or server. This embodiment takes the risk decision warning device as an example. The risk decision warning device can be integrated in terminal devices such as smart phones and tablet computers with data processing functions.
[0054] Specifically, the following are the detailed steps of an exemplary embodiment of the risk decision warning method:
[0055] Reference Figure 1 , Figure 1 This is a flow chart of the first exemplary embodiment of the risk decision warning method of the present application. In this embodiment, the risk decision warning method includes steps S10 to S40:
[0056] Step S10, extracting and reconstructing the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and storing the formatted monitoring fields in the decision conclusion ES cluster, wherein the decision conclusion information is risk decision conclusion data obtained in advance through the decision service;
[0057] In a feasible implementation, step S10 may include steps S11 to S14:
[0058] Step S11, extracting the decision conclusion fields that need to be monitored by parsing the predefined annotations of the decision conclusion information;
[0059] Specifically, by parsing the predefined annotations of the decision conclusion information, the decision conclusion fields that need to be monitored are extracted. In financial scenarios such as loan review, decision conclusion information often contains multiple fields, such as amount, interest rate, approval status, etc. In order to monitor these fields, this application introduces predefined annotations in the decision conclusion information. These annotations mark the fields that need to be monitored and provide key information such as the field type, prefix, and suffix. By parsing these annotations, the decision conclusion fields that need to be monitored can be accurately extracted.
[0060] For example, in the decision conclusion information, there is an annotation like this: "@Monitor(field='amount', type='numeric type')". After parsing this annotation, it is identified that the "amount" field needs to be monitored and its type is a numeric type.
[0061] Step S12, reconstructing the monitoring field name of the decision conclusion field according to a preset format to obtain a formatted monitoring field;
[0062] Specifically, after extracting the decision conclusion fields that need to be monitored, the decision conclusion fields are reconstructed into monitoring field names according to the preset format. The purpose of this is to ensure that when the decision conclusion fields are processed later, there will be a unified and standardized naming method, so as to facilitate management and processing.
[0063] For example, define a fixed format: "FieldTypIdEnum_Field Name_MonitorTypEnum". "FieldTypIdEnum" indicates the data type prefix of the field, which is used to match the dynamic template index of Elasticsearch (ES); "Field Name" is the decision conclusion field to be monitored; "MonitorTypEnum" indicates the type suffix of the field, which is used to distinguish whether the field is a numeric type, a code value type, or a custom type.
[0064] Take the "Amount" field as an example. Assuming its data type prefix is "NUM_", then according to the preset format, the monitoring field name of this field will be reconstructed as "NUM_Amount_Numerical Type". In this way, each decision conclusion field that needs to be monitored will have a unique and standardized monitoring field name.
[0065] Step S13, asynchronously sending the formatted monitoring fields encapsulated into Kafka messages to the decision conclusion Kafka topic;
[0066] It should be noted that Kafka is a high-throughput distributed publish-subscribe messaging system that can efficiently process large amounts of real-time data streams. By encapsulating the formatted monitoring fields into Kafka messages and sending them to Kafka topics, the Kafka topic is used as a message queue to receive and store decision conclusion information from the decision service. This information is sent asynchronously, so it will not block the execution of the decision service, thereby improving the system's throughput and response speed.
[0067] This process is done through Kafka's client API. For example, you can use Kafka's ProducerAPI to create a producer instance and send the formatted monitoring fields as the message body to the decision conclusion Kafka topic.
[0068] Specifically, each formatted monitoring field is encapsulated into a Kafka message, and the corresponding message header and message body are set. The message header contains some metadata information about the field, such as field name, data type, etc., while the message body contains the specific value of the field. These encapsulated Kafka messages are then asynchronously sent to the decision conclusion Kafka topic.
[0069] Step S14, extracting the formatted monitoring fields from the decision conclusion Kafka topic and writing them into the decision conclusion ES cluster.
[0070] Specifically, these formatted monitoring fields are pulled from the Kafka topic. These formatted monitoring fields have been marked and preprocessed by annotations, and contain the decision conclusion information that needs to be monitored and the corresponding type identifier. In order to efficiently write this data into the decision conclusion ES cluster, the stream processing framework Apache Flink can be used. Flink can process and analyze data streams in real time, supports complex event processing modes, and has high fault tolerance and scalability.
[0071] Under the action of Flink, the system will further process and transform the formatted monitoring fields extracted from Kafka to meet the storage and query requirements of the decision conclusion ES cluster. Then, Flink will write the processed data to the ES cluster in batches or streaming.
[0072] Step S20, generating a benchmark value based on the historical data of the ES cluster based on the decision conclusion;
[0073] In a feasible implementation, step S20 may include step S21:
[0074] Step S21, based on the historical data of the decision conclusion ES cluster, generate a benchmark value according to numerical value, code value and user-defined type.
[0075] Specifically, first, historical data is extracted from the decision conclusion ES cluster regularly. These historical data cover all risk decision conclusions in the past period of time. Next, the system will classify and process these historical data according to the field type, that is, numerical value, code value and custom type.
[0076] For numeric data, you can calculate its maximum and minimum values within a certain period of time (such as the last 15 days), and these two values will be used as the upper and lower limits of the field. This processing method can ensure that when real-time data exceeds this range, an early warning can be issued in time.
[0077] For code value type data, since they usually represent a certain classification or status, their numerical range will not be calculated directly. Instead, the frequency of occurrence of each code value can be counted, and the code value with the highest frequency and its corresponding number of occurrences can be recorded. This information will be used as the code value benchmark data to determine whether the code value has abnormal fluctuations in the future.
[0078] For custom data, you can develop corresponding benchmark value generation logic based on specific business needs. For example, if a custom field represents the result of a business rule, you can set a reasonable threshold as the benchmark value based on the statistical results of historical data.
[0079] In the process of generating the benchmark value, some special factors can also be taken into account, such as the impact that holidays, special events, etc. may have on the data. Therefore, when setting the benchmark value, parameterized configuration can be used to allow business personnel to adjust and optimize the calculation logic and parameters of the benchmark value.
[0080] Step S30, comparing the real-time conclusion information in the decision conclusion ES cluster with the reference value, and if the comparison result triggers a preset warning condition, storing the triggered warning detail data in the warning ES cluster;
[0081] In a feasible implementation, step S30 may include steps S31 to S33:
[0082] Step S31, comparing the real-time conclusion information in the decision conclusion ES cluster with the reference value, and judging whether the comparison result triggers an early warning according to a preset early warning condition;
[0083] Specifically, first obtain the real-time conclusion information in the decision conclusion ES cluster, and compare these real-time conclusion information with the benchmark values one by one according to the preset warning conditions. The benchmark value is generated according to historical data, numerical values, code values, and custom types, and represents the data range or threshold under normal circumstances.
[0084] For example, for the decision conclusion field of the loan approval amount, a benchmark value range can be set, such as the minimum amount and the maximum amount. When the amount in the real-time conclusion information exceeds this range, it is considered that there is an abnormal situation and an early warning needs to be triggered. At the same time, it will further determine whether an early warning needs to be triggered based on preset early warning conditions, such as the number of consecutive deviations, code value volatility, etc.
[0085] During the comparison process, efficient algorithms and data structures can be used to speed up processing and ensure that the comparison and analysis of large amounts of data can be completed in a short period of time. For example, a hash algorithm can be used to quickly find and match data. By hashing real-time conclusion information and benchmark values, a unique hash value can be generated, thereby speeding up the data search and comparison process; an index structure can be used to quickly locate the data that needs to be compared, thereby reducing unnecessary search and comparison operations.
[0086] During the comparison process, the warning rules can be dynamically adjusted according to the distribution of real-time conclusion information. For example, when the value distribution of a decision conclusion field changes significantly, the warning threshold or warning type of the field can be adjusted.
[0087] Step S32: if an early warning is triggered, the early warning detail data generated by the trigger is asynchronously sent to the early warning Kafka topic;
[0088] Specifically, if it is detected that the real-time conclusion information exceeds the preset benchmark value range, or there is a significant deviation from the benchmark value, the warning condition is met and the warning mechanism is activated. The triggered warning details are encapsulated, including key information such as the warning type, the decision conclusion field that triggers the warning, the real-time conclusion value, the benchmark value, and the warning time. Then, these warning details are asynchronously sent to the warning Kafka topic. As a message middleware, the warning Kafka topic can efficiently process and store these warning information, providing convenience for subsequent processing.
[0089] Step S33: extract the warning detail data from the warning Kafka topic, and write the warning detail data into the warning ES cluster.
[0090] Specifically, the warning details in the warning Kafka topic are extracted regularly. During the extraction process, they are screened and sorted according to the warning type, the decision conclusion field that triggers the warning, and other conditions to ensure the accuracy and efficiency of subsequent processing. Subsequently, these warning details are written to the warning ES cluster. As a distributed search engine, the warning ES cluster can quickly store, retrieve, and analyze this data. Through the warning ES cluster, it is easy to query the warning summary information, and then quickly locate the specific abnormal details for investigation, which greatly shortens the time for problem handling.
[0091] Taking a credit approval system as an example, assuming that the system sets a warning condition for the credit limit, when the real-time approval limit exceeds the preset benchmark value range, the warning is triggered. At this time, the warning details data including the warning type (such as "credit limit overlimit warning"), the decision conclusion field that triggers the warning (such as "credit limit"), the real-time approval limit, the benchmark limit, and the warning time are generated and sent asynchronously to the warning Kafka topic. Subsequently, this information is extracted from the warning Kafka topic and written to the warning ES cluster.
[0092] Step S40, generating abnormality detail data corresponding to the early warning summary data through the early warning ES cluster, and performing abnormality investigation and location according to the abnormality detail data, wherein the early warning summary data is obtained through front-end input.
[0093] In a feasible implementation, step S40 may include steps S41 to S44:
[0094] Step S41, obtaining the warning summary data input by the front end;
[0095] Specifically, we first receive the warning summary data transmitted by users or upstream services. These data usually contain key information that triggers warnings, such as warning type, decision service name, product name, monitoring indicators, and benchmark intervals. Warning summary data is set by users or systems based on business needs and risk concerns, and is used to guide subsequent warning processing and abnormality troubleshooting. After receiving these data, we will conduct preliminary verification to ensure the accuracy and completeness of the data.
[0096] For example, when receiving a warning summary data about the "credit limit" field, it will check whether the data contains key information such as the decision service name (such as "credit limit"), product name (such as "comprehensive credit"), monitoring indicator (such as "credit limit"), warning type (such as "numeric limit warning") and benchmark interval (such as "upper limit 10000, lower limit 5000"). If the data is incomplete or there is an error, the user will be prompted to correct or re-enter.
[0097] Step S42, performing a query operation in the warning ES cluster according to the warning summary data to obtain a query result;
[0098] It should be noted that the warning ES cluster is an Elasticsearch cluster specifically used to store warning-related data. It contains all real-time application data that triggers warnings and their corresponding warning information.
[0099] Specifically, determine the key fields of the query, including the decision service name, product name, monitoring indicator, and warning type, and combine these fields into a query statement in the form of key-value pairs, for example:
[0100] {"query":{"bool":{"must":[
[0101] {"match":{"decision_service_name":"Establishment of quota"}},
[0102] {"match":{"product_name":"Comprehensive Credit"}},
[0103] {"match":{"monitoring_index":"quota"}},
[0104] {"match":{"alert_type":"Numeric limit warning"}}]}}}
[0105] Next, submit the constructed query statement to the query interface of the early warning ES cluster. The early warning ES cluster will search for matching records in the stored early warning data according to the conditions in the query statement, and return all early warning records that meet the conditions. These records can contain detailed information about the triggering warning, such as the warning time, the specific value that triggered the warning, and a link to the abnormal detailed data.
[0106] Step S43, extracting abnormality detail data corresponding to the warning summary data from the query result;
[0107] Specifically, after the query result of the early warning ES cluster is obtained, the abnormal detailed data corresponding to the early warning summary data is extracted from the query result according to the key information in the early warning summary data.
[0108] For example, when extracting abnormal detailed data about the "credit limit" field, the application data that meets the conditions of "decision service name = credit limit", "product name = comprehensive credit", "monitoring indicator = credit limit" and "warning type = numerical limit warning" will be filtered out from the query results. These data will be sorted and organized according to dimensions such as application time and applicant information to facilitate abnormal investigation and location in subsequent steps.
[0109] Step S44, performing abnormality investigation and location based on the analysis results of the abnormality detailed data.
[0110] Specifically, after obtaining the abnormal detailed data, the data is analyzed and checked in depth. Based on the application time, applicant information, application amount and other information in the abnormal detailed data, combined with business rules and risk models, the abnormal data is comprehensively evaluated and analyzed. Through comparison and analysis, the specific reasons and potential risk points that lead to the warning can be located.
[0111] For example, when the system finds that the "limit" field of a certain application data exceeds the preset benchmark range, it will further analyze other relevant information of the application data, such as the applicant's credit score, historical application records, etc. Through comprehensive analysis, it can be determined whether the application data has fraud risk, credit risk or other potential risks. If the risk is confirmed, the corresponding risk disposal process will be immediately triggered, such as rejecting the application, strengthening the review, etc. At the same time, the results of abnormal investigation and positioning will be fed back to users or upstream services so that timely measures can be taken for risk prevention and control and business optimization.
[0112] Further, refer to Figure 2 , Figure 2 This is a flow chart of the second embodiment of the risk decision warning method of this application. Figure 1 In the embodiment shown, in this embodiment, step S50 may be included before step S30:
[0113] Step S50, by configuring a scheduled task, obtain the real-time conclusion information of the decision conclusion ES cluster.
[0114] Specifically, a scheduled task scheduler is set up, which can be automatically triggered at preset time intervals. When the scheduled task is triggered, it will send a query request to the decision conclusion ES cluster to obtain the latest real-time conclusion information. In order to ensure the accuracy and completeness of the real-time conclusion information, the query request will be made to the specific indexes in the decision conclusion ES cluster, which are optimized and classified according to the annotations and field types of the decision conclusions. The obtained real-time conclusion information will be temporarily stored in the memory for subsequent comparison and analysis with the benchmark value.
[0115] Further, refer to Figure 2 , Figure 2 This is a flow chart of the second embodiment of the risk decision warning method of this application. Figure 1 In the embodiment shown, in this embodiment, before step S10, steps S01 to S02 may be included:
[0116] Step S01, performing risk assessment based on input risk assessment data to generate decision conclusion information;
[0117] In the risk assessment stage, we first receive risk assessment data from various business channels. This data may include but is not limited to the applicant's credit record, income status, debt status, collateral value and other information. This data is analyzed using a preset risk assessment model, which may contain multiple complex algorithms and logical judgments to assess the applicant's risk level. Based on the results of the risk assessment, decision conclusion information is generated, which usually includes decision factors such as loan amount, interest rate, and approval status.
[0118] For example, an applicant submits a loan application, and the system receives the risk assessment data of the application. This data includes information such as the applicant's income certificate, job stability, and past credit record. The risk assessment model analyzes this data and concludes that the applicant's risk level is "medium". Based on this risk level, a decision conclusion is generated, that is, the applicant's loan application is approved, but the loan amount is slightly lower than that of ordinary applicants, and the interest rate remains unchanged.
[0119] Step S02: Mark the information that needs to be monitored in the decision conclusion information by using predefined annotations.
[0120] It should be noted that annotations are metadata added to the code to provide additional descriptive information for data fields. In an embodiment, annotations are used to mark which fields in the decision conclusion information need to be monitored. For example, if "amount" and "interest rate" may be two key fields that need to be monitored, predefined annotations such as "@MonitorField(type="numeric type")" will be added to these fields to indicate that these fields need to be included in the monitoring scope and that their type is a numeric type. In this way, when the values of these fields fluctuate abnormally, they can be captured in time and the early warning mechanism can be triggered.
[0121] In addition, the present application also proposes a risk decision warning device, which includes:
[0122] The preamble module 10 is used to extract and reconstruct the decision conclusion information based on the predefined annotations to obtain the formatted monitoring fields, and store the formatted monitoring fields in the decision conclusion ES cluster, wherein the decision conclusion information is the risk decision conclusion data obtained in advance through the decision service;
[0123] A reference value generating module 20, for generating a reference value based on the historical data of the decision conclusion ES cluster;
[0124] The monitoring and warning module 30 is used to compare the real-time conclusion information in the decision conclusion ES cluster with the reference value. If the comparison result triggers the preset warning condition, the warning detail data generated by the trigger is stored in the warning ES cluster;
[0125] The abnormality checking module 40 is used to generate abnormality detail data corresponding to the early warning summary data through the early warning ES cluster, and to check and locate the abnormality according to the abnormality detail data. The early warning summary data is obtained through the front-end input.
[0126] The risk decision warning device provided by the present application adopts the risk decision warning method in the above embodiment, aiming to solve the technical problems of low efficiency and easy error in monitoring warning configuration and difficulty in troubleshooting abnormal decision conclusions. Compared with the prior art, the beneficial effects of the risk decision warning device provided by the present application are the same as those of the risk decision warning method provided by the above embodiment, and the other technical features in the risk decision warning device are the same as those disclosed in the above embodiment method, which will not be described in detail here.
[0127] The present application provides a risk decision warning device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the risk decision warning method in the above-mentioned embodiment one.
[0128] Reference below Figure 5 , which shows a schematic diagram of the structure of the risk decision warning device used to implement the embodiment of the present application. The risk decision warning device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The risk decision warning device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.
[0129] like Figure 5 As shown, the risk decision warning device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the risk decision warning device are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the risk decision warning device to communicate with other devices wirelessly or by wire to exchange data. Although the risk decision warning device with various systems is shown in the figure, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.
[0130] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.
[0131] The risk decision warning device provided by this application adopts the risk decision warning method in the above embodiment, aiming to solve the technical problems of low efficiency and easy error in monitoring warning configuration and difficulty in troubleshooting abnormal decision conclusions. Compared with the prior art, the beneficial effects of the risk decision warning device provided by this application are the same as the beneficial effects of the risk decision warning method provided by the above embodiment, and the other technical features in the risk decision warning device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.
[0132] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.
[0133] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
[0134] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the risk decision warning method in the above-mentioned embodiment.
[0135] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.
[0136] The computer-readable storage medium may be included in the risk decision warning device; or it may exist independently without being assembled into the risk decision warning device.
[0137] Computer program code for performing the operations of the present application may be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0138] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0139] The modules involved in the embodiments described in the present application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.
[0140] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned risk decision warning method, aiming to solve the technical problems of low efficiency and error-prone monitoring and warning configuration, and difficulty in troubleshooting abnormal decision conclusions. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the risk decision warning method provided in the above-mentioned embodiment, and will not be elaborated here.
[0141] The present application also provides a computer program product, including a computer program, which implements the steps of the risk decision warning method as described above when executed by a processor.
[0142] The computer program product provided by this application is intended to solve the technical problems of low efficiency and error-prone monitoring and early warning configuration, and difficulty in troubleshooting abnormal decision conclusions. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as those of the risk decision early warning method provided by the above embodiment, and will not be elaborated here.
[0143] Compared with the prior art, the risk decision warning method, device, equipment, medium and computer product proposed in the embodiment of the present application extracts the business feature information of the target business, performs data standardization processing on the business feature information, obtains standard feature data, performs hash processing on the standard feature data, obtains unique feature data, performs numerical processing and splicing processing on the unique feature data, obtains the first business feature value, accumulates the first business feature value of the target business, obtains the target business feature value, and finally compares the target business feature value with the feature value set to obtain the risk decision warning result. Compared with the traditional method of identifying duplicate businesses by generating a unique key value or a continuous serial number for each business, it is more efficient, flexible and reliable. Based on the solution of the present application, by subjecting the business of complex scenarios to a series of simple transformations and finally converting it into a comparison of two numbers, the comparison process is very intuitive and efficient. The system only needs to simply compare whether the two values are equal to quickly determine whether the two businesses are exactly the same.
[0144] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or system including the element.
[0145] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.
[0146] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as above, and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, a controlled terminal, or a network device, etc.) to execute the method of each embodiment of the present application.
[0147] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.
Claims
1. A risk decision early warning method, characterized in that: The risk decision early warning method comprises: Extract and reconstruct the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and store the formatted monitoring fields in the decision conclusion ES cluster, where the decision conclusion information is risk decision conclusion data obtained in advance through the decision service; Generate a benchmark value based on the historical data of the ES cluster based on the decision conclusion; The real-time conclusion information in the decision conclusion ES cluster is compared with the reference value. If the comparison result triggers the preset warning condition, the generated warning detail data is stored in the warning ES cluster; The abnormality detail data corresponding to the early warning summary data is generated by the early warning ES cluster, and the abnormality is checked and located according to the abnormality detail data. The early warning summary data is obtained through the front-end input.
2. The risk decision early warning method according to claim 1, characterized in that: The step of extracting and reconstructing the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and storing the formatted monitoring fields in the decision conclusion ES cluster, wherein the decision conclusion information is risk decision conclusion data obtained in advance through the decision service, comprises: By parsing the predefined annotations of decision conclusion information, the decision conclusion fields that need to be monitored are extracted; Reconstruct the monitoring field name of the decision conclusion field according to a preset format to obtain a formatted monitoring field; Asynchronously sending the formatted monitoring fields encapsulated into Kafka messages to the decision conclusion Kafka topic; The formatted monitoring fields are extracted from the decision conclusion Kafka topic and written into the decision conclusion ES cluster.
3. The risk decision early warning method according to claim 2, characterized in that: The step of generating a benchmark value based on the historical data of the ES cluster based on the decision conclusion includes: Based on the historical data of the ES cluster of the decision conclusion, the benchmark value is generated according to the numerical value, code value and custom type.
4. The risk decision early warning method according to claim 1, characterized in that: The step of comparing the real-time conclusion information in the decision conclusion ES cluster with the reference value, and if the comparison result triggers a preset warning condition, storing the triggered warning detail data into the warning ES cluster includes: Compare the real-time conclusion information in the decision conclusion ES cluster with the benchmark value, and determine whether the comparison result triggers an early warning according to the preset early warning condition; If an alert is triggered, the alert details generated by the trigger will be asynchronously sent to the alert Kafka topic; The warning detail data is extracted from the warning Kafka topic, and the warning detail data is written into the warning ES cluster.
5. The risk decision early warning method according to claim 1, characterized in that: The step of comparing the real-time conclusion information in the decision conclusion ES cluster with the benchmark value, and if the comparison result triggers a preset warning condition, storing the triggered warning detail data in the warning ES cluster also includes: By configuring scheduled tasks, you can obtain real-time conclusion information of the ES cluster.
6. The risk decision early warning method according to claim 1, characterized in that: The step of generating abnormality detail data corresponding to the early warning summary data through the early warning ES cluster, performing abnormality investigation and positioning according to the abnormality detail data, and obtaining the early warning summary data through the front-end input includes: Get the warning summary data input by the front end; According to the warning summary data, a query operation is performed in the warning ES cluster to obtain a query result; Extracting abnormality detail data corresponding to the early warning summary data from the query result; Anomalies are checked and located based on the analysis results of the abnormal detailed data.
7. The risk decision early warning method according to claim 1, characterized in that: The step of extracting and reconstructing the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and storing the formatted monitoring fields in the decision conclusion ES cluster, wherein the decision conclusion information is risk decision conclusion data obtained in advance through the decision service, also includes: Perform risk assessment based on input risk assessment data to generate decision conclusion information; The information that needs to be monitored in the decision conclusion information is marked by predefined annotations.
8. A risk decision warning device, characterized in that: The device comprises: The pre-order module is used to extract and reconstruct the decision conclusion information based on predefined annotations to obtain formatted monitoring fields, and store the formatted monitoring fields in the decision conclusion ES cluster. The decision conclusion information is the risk decision conclusion data obtained in advance through the decision service; A benchmark value generation module, used to generate a benchmark value based on the historical data of the decision conclusion ES cluster; A monitoring and early warning module is used to compare the real-time conclusion information in the decision conclusion ES cluster with the benchmark value. If the comparison result triggers a preset early warning condition, the triggered early warning detail data is stored in the early warning ES cluster; The abnormality investigation module is used to generate abnormality detail data corresponding to the early warning summary data through the early warning ES cluster, and perform abnormality investigation and positioning according to the abnormality detail data. The early warning summary data is obtained through front-end input.
9. A risk decision warning device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the risk decision warning method according to any one of claims 1 to 7.
10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the risk decision warning method according to any one of claims 1 to 7 are implemented.