Transaction method and device based on event-driven customized letter, and electronic equipment

Abstract

The invention provides a transaction method and device based on event-driven customized credit, and electronic equipment, and the method comprises the steps: extracting transaction features of a transaction event under the condition that the transaction event is monitored, carrying out the matching with a transaction routing unit according to the transaction features, so as to determine a target transaction scene, the transaction routing unit comprises preset rule sets corresponding to different transaction scenes; according to the target transaction scene, calling a corresponding quota management and control unit to obtain a target credit using rule, different quota management and control units including quota credit using rules in different transaction scenes; according to the target credit using rule, calling a corresponding quota type unit to obtain a target quota attribute, different quota type units including quota attributes in different transaction scenes; and calculating an actual transaction quota according to the target credit using rule and the target quota attribute, and executing a transaction event according to the actual transaction quota. According to the method, the problem of insufficient resource utilization caused by a fixed-limit allocation mechanism in the prior art is solved.

Description

Technical Field

[0001] This invention relates to the field of financial management technology, and more specifically, to a transaction method, apparatus, computer-readable storage medium, and electronic device based on event-driven customized credit. Background Technology

[0002] In the management of credit card limits in the financial sector, traditional credit schemes rely on static limit allocation mechanisms. Specifically, a fixed limit is set for each user. However, with the rapid development of the credit card business and the increasing complexity of transaction scenarios and usage logs, the rigid mechanism makes it difficult to fully utilize resources.

[0003] Understandably, the current credit limit allocation method treats all credit limits as the same pool, resulting in users using the same fixed credit limit in different transaction scenarios. This one-size-fits-all approach leads to the inability to effectively differentiate and utilize credit limit resources in different transaction scenarios, such as local consumption and cross-border e-commerce shopping, resulting in low resource utilization. According to statistics, some credit card users have a credit limit resource utilization rate of less than 60%. Summary of the Invention

[0004] The main objective of this application is to provide a transaction method, apparatus, computer-readable storage medium, and electronic device based on event-driven customized credit, so as to at least solve the problem of insufficient resource utilization caused by the fixed quota allocation mechanism in the prior art.

[0005] To achieve the above objectives, according to one aspect of this application, a transaction method for customized credit usage based on event-driven mechanisms is provided, comprising: upon detecting a transaction event, extracting transaction features of the transaction event; matching the transaction features with a transaction routing unit to determine a target transaction scenario, wherein the transaction routing unit includes a set of preset rules corresponding to different transaction scenarios; invoking a corresponding credit limit control unit according to the target transaction scenario to obtain a target credit usage rule, wherein different credit limit control units include credit usage rules under different transaction scenarios; invoking a corresponding credit limit type unit according to the target credit usage rule to obtain a target credit limit attribute, wherein different credit limit type units include credit limit attributes under different transaction scenarios; calculating an actual transaction limit based on the target credit usage rule and the target credit limit attribute; and executing the transaction event based on the actual transaction limit.

[0006] Optionally, the transaction features of the transaction event are extracted, and the transaction features are matched with the transaction routing unit to determine the target transaction scenario. This includes: extracting the transaction object, transaction method, transaction amount, and transaction type of the transaction event to obtain the transaction features; matching the transaction features with each of the preset rule sets; and determining the transaction scenario corresponding to the matched preset rule set as the target transaction scenario.

[0007] Optionally, the target credit rule is obtained by calling the corresponding credit limit management unit according to the target transaction scenario, including: querying a first mapping relationship according to the target transaction scenario to obtain the target management unit, wherein the first mapping relationship is a mapping relationship between the transaction scenario and the credit limit management unit; extracting the credit limit rules in the target management unit to obtain the first credit rule; matching the first credit rule with the feature type of the transaction feature, and filtering the matched first credit rule through parameterized checks and priority filtering to obtain the target credit rule.

[0008] Optionally, the first credit rules that match are filtered through parameterized checks and priority filtering to obtain the target credit rules, including: verifying the feature parameters of the transaction features according to the check conditions and check thresholds of each of the first credit rules that match; if the verification passes, determining whether each of the first credit rules can coexist through preset code parameters; if each of the first credit rules can coexist, determining each of the first credit rules as the target credit rules; if each of the first credit rules cannot coexist, determining the first credit rule with the highest priority as the target credit rule.

[0009] Optionally, calling the corresponding credit limit type unit according to the target credit limit rule to obtain the target credit limit attribute includes: querying a second mapping relationship according to the target credit limit rule to obtain the target credit limit unit, wherein the second mapping relationship is the mapping relationship between the credit limit rule and the credit limit type unit; extracting the credit limit attribute from the target credit limit unit to obtain the first credit limit attribute; and calculating the actual value of the first credit limit attribute according to the target credit limit rule to obtain the target credit limit attribute.

[0010] Optionally, calculating the actual transaction amount based on the target credit rule and the target credit limit attribute includes: extracting a credit limit check summary from the target credit rule, wherein the credit limit check summary is used to characterize the restriction relationship between different types of credit limit attributes; and modifying each of the target credit limit attributes based on the credit limit check summary to obtain the actual transaction amount.

[0011] Optionally, executing the transaction event based on the actual transaction amount includes: if there are multiple actual transaction amounts, taking the minimum value of the actual transaction amount and executing the transaction event.

[0012] According to another aspect of this application, an event-driven customized credit transaction device is provided, comprising: an acquisition unit, configured to extract transaction features of a transaction event upon detection of such an event, and match the transaction features with a transaction routing unit to determine a target transaction scenario, wherein the transaction routing unit includes a set of preset rules corresponding to different transaction scenarios; a first processing unit, configured to call a corresponding credit limit control unit according to the target transaction scenario to obtain target credit rules, wherein different credit limit control units include credit limit rules for different transaction scenarios; a second processing unit, configured to call a corresponding credit limit type unit according to the target credit rules to obtain target credit limit attributes, wherein different credit limit type units include credit limit attributes for different transaction scenarios; and a calculation unit, configured to calculate an actual transaction limit based on the target credit rules and the target credit limit attributes, and execute the transaction event based on the actual transaction limit.

[0013] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform any of the methods described.

[0014] According to another aspect of this application, an electronic device is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including methods for performing any one of the methods described.

[0015] Applying the technical solution of this application, in the aforementioned event-driven customized credit transaction method, firstly, upon detecting a transaction event, the transaction characteristics of the event are extracted, and matched with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios. Then, the corresponding credit limit management unit is called according to the target transaction scenario to obtain the target credit rule. Different credit limit management units include credit limit rules for different transaction scenarios. Next, the corresponding credit limit type unit is called according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes for different transaction scenarios. Finally, the actual transaction amount is calculated based on the target credit rule and the target credit limit attribute, and the transaction event is executed based on the actual transaction amount. Through the implementation of this solution, credit card credit limit management has achieved significant technological progress and business optimization. Firstly, dynamic scenario-based credit limit allocation greatly improves the utilization rate of credit limit resources. Adjusting credit limit allocation in real time according to different transaction characteristics allows users to obtain credit support that better suits their needs in various transaction scenarios. Secondly, the introduction of the parameterized rule factor engine enables risk control strategies to respond quickly to market changes, reduce the misjudgment rate of scenarios, and further improve the accuracy of resource allocation. Finally, the transaction event-driven quota control unit design not only enhances the system's flexibility but also significantly shortens the response time for quota calculation and control, improving user experience. It also provides financial institutions with a more efficient and secure means of quota management, solving the problem of insufficient resource utilization caused by the fixed quota allocation mechanism in existing technologies. Attached Figure Description

[0016] Figure 1 A hardware structure block diagram of a mobile terminal for an event-driven customized credit transaction method provided in an embodiment of this application is shown.

[0017] Figure 2 A flowchart illustrating an event-driven customized credit transaction method according to an embodiment of this application is shown.

[0018] Figure 3 A structural block diagram of an event-driven customized transaction device according to an embodiment of this application is shown.

[0019] The above figures include the following reference numerals:

[0020] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] As described in the background section, existing credit limit allocation methods treat all credit limits as a single pool, resulting in users using the same fixed credit limit across different transaction scenarios. This one-size-fits-all approach leads to an inability to effectively differentiate and utilize credit limit resources in different transaction scenarios, such as local consumption and cross-border e-commerce shopping, resulting in low resource utilization. Statistics show that some credit card users have a credit limit utilization rate of less than 60%. To address the problem of insufficient resource utilization caused by the fixed credit limit allocation mechanism in existing technologies, embodiments of this application provide a transaction method, apparatus, computer-readable storage medium, and electronic device based on event-driven customized credit card usage.

[0025] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0026] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for an event-driven customized transaction method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0027] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the event-driven customized credit transaction method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0028] This embodiment provides an event-driven custom credit transaction method that runs on a mobile terminal, computer terminal, or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0029] Figure 2 This is a flowchart of an event-driven customized credit transaction method according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0030] Step S201: When a transaction event is detected, the transaction features of the transaction event are extracted, and the transaction features are matched with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios.

[0031] Understandably, this step utilizes an event-driven architecture (EDA) to trigger a system response when a transaction occurs. By analyzing transaction data in real time, it extracts key information such as transaction amount, transaction time, transaction location, merchant category code (MCC), and customer credit score, which is then used to match transaction scenarios in the future.

[0032] Specifically, when a transaction occurs, the system first analyzes the received transaction event to extract key transaction features. For example, for an online shopping transaction, the system will analyze the transaction data to extract information such as the transaction amount, merchant category code, and transaction time. This information will then be used to match the data against a pre-defined set of rules in the transaction routing unit to determine the target transaction scenario.

[0033] Through the above operations, by listening to and extracting transaction features in real time, the system can respond quickly to transaction events, laying the foundation for subsequent scenario matching and quota calculation, and effectively improving the real-time performance and security of transaction processing.

[0034] Step S202: Based on the target transaction scenario, call the corresponding credit limit control unit to obtain the target credit usage rules. Different credit limit control units include credit limit usage rules under different transaction scenarios.

[0035] Understandably, based on the transaction scenario determined by the transaction characteristics, a pre-configured credit limit control unit is invoked. Each credit limit control unit contains credit rules for a specific scenario, which define the calculation logic and control strategy for the available credit limit in that scenario.

[0036] Specifically, after identifying the target transaction scenario, the system will invoke the corresponding credit limit control unit based on the scenario type. The parameterized rule engine within the credit limit control unit will dynamically calculate the available credit limit based on preset scenario credit rules, such as credit limit type, credit limit calculation ratio, and risk threshold.

[0037] Through the above operations, by calling the credit limit management unit, the system can apply customized credit rules based on the transaction scenario, achieve precise management and risk control of the credit limit, and improve the rationality of credit limit allocation and transaction security.

[0038] Step S203: Call the corresponding credit limit type unit according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes under different transaction scenarios.

[0039] Understandably, the credit limit type unit is defined based on different credit limit types and attributes according to the customer lifecycle and transaction scenario. The target credit rule will guide the system to call the correct credit limit type unit to obtain the credit limit attributes applicable to the current transaction scenario.

[0040] Specifically, after applying the target credit rule, the system will further call the corresponding credit limit type unit, which will provide specific credit limit attributes under the target transaction scenario, such as total credit limit, available credit limit, validity period, etc.

[0041] Through the above operations, by calling the quota type unit, the system can obtain the quota attributes that match the transaction scenario, realizing the refined management and efficient utilization of quota resources, while enhancing the flexibility and response speed of quota allocation.

[0042] Step S204: Calculate the actual transaction amount based on the target credit rules and target credit limit attributes, and execute the transaction event based on the actual transaction amount.

[0043] Understandably, this step combines the target credit rules and target credit limit attributes, and uses a real-time calculation engine to dynamically calculate the actual transaction amount, ensuring that the transaction is conducted within the scope of credit limit control and risk assessment.

[0044] Specifically, the system takes the target credit rules and target credit limit attributes as input and calculates the actual transaction amount through a real-time computing engine driven by an in-memory database. For example, it may calculate based on the correlation between cash withdrawal and consumption limits, or dynamically adjust the available credit limit according to the risk level in the rule factors.

[0045] Through the above operations, the actual transaction amount is calculated in real time, ensuring the compliance and security of transactions. At the same time, it improves the efficiency of transaction processing, optimizes the user experience, and enables the system to respond to and process transaction events quickly, avoiding misuse of quotas and waste of resources.

[0046] In this embodiment, firstly, upon detecting a transaction event, the transaction characteristics of the event are extracted. These characteristics are then matched with a transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios. Next, the corresponding credit limit management unit is invoked based on the target transaction scenario to obtain the target credit usage rule. Different credit limit management units include credit usage rules for different transaction scenarios. Then, the corresponding credit limit type unit is invoked based on the target credit usage rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes for different transaction scenarios. Finally, the actual transaction amount is calculated based on the target credit usage rule and the target credit limit attribute, and the transaction event is executed based on the actual transaction amount. Through the implementation of this solution, credit card credit limit management has achieved significant technological advancements and business optimizations. Firstly, dynamic scenario-based credit limit allocation greatly improves the utilization rate of credit limit resources. Adjusting credit limit allocation in real time based on different transaction characteristics allows users to obtain credit support that better meets their needs in various transaction scenarios. Secondly, the introduction of a parameterized rule factor engine enables risk control strategies to quickly respond to market changes, reduce scenario misjudgment rates, and further improve the accuracy of resource allocation. Finally, the transaction event-driven quota control unit design not only enhances the system's flexibility but also significantly shortens the response time for quota calculation and control, improves the user experience, and provides financial institutions with a more efficient and secure means of quota management, solving the problem of insufficient resource utilization caused by the fixed quota allocation mechanism in existing technologies.

[0047] To determine the aforementioned target transaction scenario, in one optional implementation, step S201 includes:

[0048] Step S2011: Extract the transaction object, transaction method, transaction amount, and transaction type of the transaction event to obtain the transaction characteristics;

[0049] Understandably, the core of this step is event feature extraction technology, which uses data parsing algorithms to extract key features from transaction events for subsequent scenario matching and quota calculation. This step is the starting point of the entire process, ensuring that subsequent processing is based on sufficient information.

[0050] Specifically, when a transaction event occurs, the system captures and parses the transaction data in real time through an event stream processing framework, extracting transaction features, including but not limited to the transaction timestamp, the object of the transaction (such as merchant information), the type of transaction (such as transfer, consumption, cash withdrawal), the amount of the transaction, and the specific method of the transaction (such as online or offline). These features are then used to match the data with a set of preset rules in the transaction routing unit to determine the target transaction scenario.

[0051] By performing the above operations, the rapid and accurate extraction of transaction features ensures that subsequent processing is based on accurate information, improves the accuracy of scenario matching, and thus provides a solid data foundation for the dynamic calculation of credit limits, enhancing the effectiveness of risk assessment.

[0052] Step S2012: Match the transaction characteristics with each preset rule set;

[0053] Understandably, this step relies on rule engine technology, which matches transaction characteristics with a set of configurable rules, automatically identifies which specific scenario a transaction belongs to, and then determines which credit limit control units and corresponding credit rules to invoke.

[0054] Specifically, the extracted transaction features are input into the rule engine, which then matches them against a pre-defined set of rules to find rules that match these features. Each pre-defined set of rules is associated with a specific transaction scenario, and a successful match with a rule set means that the target transaction scenario has been identified.

[0055] Through the above operations, rule matching can automatically and quickly identify transaction scenarios, reduce manual intervention, improve efficiency, and reduce error rates, providing a clear direction for subsequent quota calculation and control.

[0056] Step S2013: Determine the transaction scenario corresponding to the set of preset rules that match the target transaction scenario.

[0057] Understandably, once a transaction characteristic successfully matches a set of preset rules, this step will clarify the transaction scenario based on the definition of that set of rules, thereby providing a basis for subsequent quota control.

[0058] Specifically, after rule matching is completed, the system will directly mark the transaction scenario corresponding to the matched rule set as the target transaction scenario. This information will be recorded and transmitted to the next processing step, namely the selection of the quota control unit and the invocation of quota attributes.

[0059] By clarifying the transaction scenario through the above operations, the system can accurately apply the appropriate quota control rules, achieve more reasonable and efficient quota allocation and risk control, and ensure the security and rationality of transactions.

[0060] Through the above embodiments, transaction features are captured in real time, and transaction scenarios are quickly matched, ensuring the timeliness of quota calculation and the accuracy of scenario identification, reducing transaction processing waiting time and misjudgment rate. Quota calculation driven by transaction scenarios can flexibly adjust quota size and control strategies according to the characteristics and risk levels of different transaction types, enhancing the system's risk response capabilities. The system's automated processing capabilities enable users to experience a smoother and safer service experience when conducting transactions, especially in high-frequency trading or complex scenarios, where the improvement in user experience is particularly significant.

[0061] To determine the aforementioned target credit rules, in one optional implementation, step S202 includes:

[0062] Step S2021: Query the first mapping relationship based on the target transaction scenario to obtain the target control unit. The first mapping relationship is the mapping relationship between the transaction scenario and the quota control unit.

[0063] Understandably, this step is based on database query technology, using the target transaction scenario as the query key to find the corresponding quota control unit from the predefined first mapping relationship, thereby realizing the automatic link between the transaction scenario and the quota control logic.

[0064] Specifically, the first mapping relationship is stored in the system, defining the correspondence between transaction scenarios and quota control units. Once transaction characteristics are identified and the target transaction scenario is determined, the system will query the database for all quota control units corresponding to this scenario. These units typically contain quota management strategies and rules for that specific scenario.

[0065] Through the above operations, by querying the first mapping relationship, the system can automatically identify the quota control unit corresponding to a specific scenario, providing specific operational guidelines for subsequent quota calculation and control, and improving the accuracy and processing efficiency of business logic.

[0066] Step S2022: Extract the credit limit rules from the target control unit to obtain the first credit limit rule;

[0067] Understandably, after invoking the credit limit management unit, the rule engine technology is used to extract the credit limit usage rules within the specific unit. These rules will be used for the next step of matching and filtering to determine the final credit usage strategy.

[0068] Specifically, the system extracts rules for each target control unit. These rules may include different types of credit limit calculation formulas, credit limit percentages, validity periods, and risk control thresholds. All extracted credit limit rules will be marked as the first set of credit limit rules, ready for the next step of matching and filtering.

[0069] Through the above operations, the credit rules in the target control unit are extracted, providing detailed guidance for the accurate calculation and differentiated management of the credit limit, ensuring the rationality and security of the transaction limit, and enhancing the system's ability to handle complex scenarios.

[0070] Step S2023: Match the transaction feature type with the first credit rule, and filter the matched first credit rule through parameterization check and priority filtering to obtain the target credit rule.

[0071] Understandably, this step involves advanced rule matching algorithms and parameterized checking techniques. By further analyzing transaction characteristics, it determines the credit limit rules that are truly applicable in the current transaction scenario, ensuring the accuracy of credit limit calculation, while also taking into account rule priority to avoid conflicts.

[0072] Specifically, transaction characteristics are matched against the first set of credit rules. The system will compare each transaction characteristic with the first set of credit rules to find the applicable rule. Then, parameterized checks are used to further confirm the validity and applicability of the rule, such as checking whether the transaction amount exceeds the prescribed limit and whether the transaction time conforms to the validity period of the credit limit. Finally, a priority filtering mechanism ensures that, if multiple rules meet the conditions, the rule with the highest priority is selected as the final target credit rule.

[0073] Through the above operations, and through meticulous matching, checking and screening, the system can ensure that the most appropriate credit rules are selected in any transaction scenario. This not only optimizes the allocation and use of credit limits, but also strengthens the effectiveness of risk control strategies, avoiding credit limit mismatch and potential risks.

[0074] Through the above embodiments, the system can automatically invoke and filter the most suitable credit limit rules based on specific transaction scenarios and characteristics, greatly improving the accuracy of credit limit management. The introduction of a parameterized checking mechanism ensures that applicable credit limit rules not only match transaction characteristics but also comply with specific business parameters and risk thresholds, improving the flexibility and adaptability of the rules. By setting and filtering rule priorities, the system can prioritize handling more urgent or important credit limit configuration needs, avoiding uncertainty when multiple rules apply simultaneously, and enhancing the consistency and coherence of decision-making.

[0075] To ensure the accuracy of the aforementioned target credit rules, in an optional implementation, step S2023 includes:

[0076] Step S20231: Verify the feature parameters of the transaction features according to the check conditions and check thresholds of each first credit rule that has been matched.

[0077] Understandably, after rule matching, the system needs to ensure that these rules apply to the current transaction. This step is accomplished through parametric validation. Parametric validation allows the system to dynamically adjust variables in the rules, such as transaction amount, time, and customer credit rating, to ensure they meet specific check conditions and thresholds.

[0078] Specifically, the system will verify the check conditions and thresholds in each successfully matched first-time credit rule to confirm whether these rules match the current transaction characteristics. This process may include comparing whether the transaction amount exceeds the prescribed limit, whether the transaction time is within the validity period of the credit limit, and whether the customer's credit rating meets specific threshold requirements, etc.

[0079] Through the above embodiments, parameterized checks ensure the applicability of credit rules, avoid improper quota usage or risk control failure caused by rule mismatch, and improve the accuracy and security of transaction processing.

[0080] Step S20232: If the verification passes, determine whether each first-user rule can coexist by using preset code parameters;

[0081] Understandably, different credit rules may target different aspects of a transaction, and there may be conflicts or coexistence between them. This step, through rule compatibility analysis, ensures that the rules applied simultaneously do not contradict each other and affect the normal progress of the transaction.

[0082] Specifically, if the initial parameterization check passes, the system will further analyze whether these rules can be applied together in the current transaction. For example, the system will check whether simultaneously invoking overpayment and cash withdrawal limits would violate the total credit limit, or whether there is a situation where a certain rule excludes the application of other rules.

[0083] Through the above operations, the coexistence analysis of rules helps the system understand and execute multi-dimensional quota control strategies, ensuring that customer needs are met as much as possible without affecting transaction security, thereby improving the flexibility and efficiency of quota management.

[0084] Step S20233: If each first credit rule can coexist, determine each first credit rule as the target credit rule;

[0085] Understandably, when the system determines that all matching rules can coexist without conflict, these rules will be adopted as a comprehensive set of quota control strategies to address the current trading scenario.

[0086] Specifically, once the coexistence of rules is confirmed, the system integrates all the first credit rules that pass the verification into a set of target credit rules, which are used to guide the calculation and allocation of subsequent credit limits.

[0087] Through the above operations, the coexistence rules are integrated into a set of target credit rules, enabling the system to comprehensively consider multiple credit limit requirements and risk factors, thus achieving more comprehensive and detailed credit limit management and risk control.

[0088] Step S20234: If the first credit rules cannot coexist, the first credit rule with the highest priority is determined as the target credit rule.

[0089] Understandably, when conflicting rules exist, the system will select the rule with the highest priority based on the rule priority ranking mechanism to guide the calculation and allocation of transaction limits.

[0090] Specifically, if conflicts are found between certain credit rules during coexistence analysis, the system will sort them according to the pre-set priority of each rule and select the rule with the highest priority as the final target credit rule for the calculation of credit limits and the execution of transactions.

[0091] Through the above operations, priority screening ensures that the system can make reasonable decisions in conflict rules, avoiding transaction delays or rejections caused by rule conflicts, while maintaining the rigor of quota management and the initiative of risk control.

[0092] Through the above embodiments, parameterized checks ensure the applicability of the rules, enabling dynamic adjustments based on the specific circumstances of each transaction, thus improving the accuracy and efficiency of quota calculation. Analysis of coexisting rules allows the system to comprehensively apply multiple rules without conflict, meeting quota requirements in diverse transaction scenarios. In the event of rule conflicts, decisions are made based on priority ranking, ensuring consistency and fairness in quota management under complex scenarios while reducing uncertainty in transaction processing.

[0093] To determine the aforementioned target quota attributes, in one optional implementation, step S203 includes:

[0094] Step S2031: Query the second mapping relationship according to the target credit rule to obtain the target credit limit unit. The second mapping relationship is the mapping relationship between the credit limit rule and the credit limit type unit.

[0095] Understandably, this step utilizes database query technology and rule mapping mechanisms to ensure the correct association between the target credit rule and the credit limit type unit, which is a crucial preliminary step in obtaining credit limit attributes.

[0096] Specifically, the second mapping relationship stores the mapping details between credit limit usage rules and credit limit type units. Once the system determines the target credit limit rules, it will query the second mapping relationship based on these rules to locate the corresponding credit limit type unit. Each credit limit type unit represents a set of attributes for a type of credit limit (such as consumption limit, cash withdrawal limit), such as total limit, validity period, and number of uses.

[0097] Through the above operations, by querying the second mapping relationship, the system can accurately call the credit limit type unit that matches the credit rule, ensuring the relevance and accuracy of the credit limit attribute acquisition, and laying a precise foundation for the next step of credit limit calculation.

[0098] Step S2032: Extract the credit limit attribute from the target credit limit unit to obtain the first credit limit attribute;

[0099] Understandably, data warehousing and data mining technologies play a crucial role here, enabling the system to extract specific credit attributes from target credit units and provide detailed parameters for credit calculation.

[0100] Specifically, after a target credit limit unit is invoked, the system extracts credit limit attributes from that unit. These attributes include, but are not limited to, total credit limit, validity period, single spending limit, and cumulative spending count. These primary credit limit attributes constitute the basic components of the credit limit type and will be used for subsequent calculations and management.

[0101] Through the above operations, the process of extracting the first quota attribute enables the system to obtain detailed information on the quota required for the current transaction scenario, providing specific data support for the dynamic calculation of the quota and risk assessment, and ensuring the refinement and scenario-based nature of quota management.

[0102] Step S2033: Calculate the actual value of the first credit limit attribute according to the target credit rule to obtain the target credit limit attribute.

[0103] Understandably, the most crucial calculation step in credit limit management is to use mathematical models and algorithms, combined with target credit rules and the primary credit limit attribute, to calculate the actual usable credit limit value in a specific transaction scenario.

[0104] Specifically, based on the target credit rules and the extracted first credit limit attribute, the system dynamically calculates the actual value of the target credit limit attribute through a real-time calculation engine. During the calculation process, factors such as the calculation ratio of the credit limit and the risk adjustment coefficient may need to be considered to ensure that the calculation result meets business needs while remaining within a controllable risk range.

[0105] Through the above operations, the process of calculating the target credit limit attributes not only enables dynamic adjustment of the credit limit, but also fully considers risk control factors, ensuring the flexibility and security of credit limit management in complex scenarios and improving the utilization efficiency of credit limit resources.

[0106] Through the above embodiments, the system can quickly locate the correct credit limit type unit based on transaction characteristics, ensuring the accuracy of credit limit attribute acquisition and improving the scenario adaptability and personalized service level of credit limit management. The combination of a real-time calculation engine and target credit rules enables the system to dynamically adjust credit limit attributes in a rapidly changing transaction environment, meeting business needs while strengthening risk control, achieving efficient resource utilization and effective risk management. Scenario-based credit limit management and real-time dynamic adjustment significantly optimize the user experience of credit limits in different transaction scenarios, reducing the inconvenience caused by static credit limit allocation mechanisms and increasing trust and satisfaction in the transaction process.

[0107] In order to determine the user's actual transaction amount, in one optional implementation, step S204 above includes:

[0108] Step S2041: Extract the credit limit check summary from the target credit rule. The credit limit check summary is used to characterize the restriction relationship between different types of credit limit attributes.

[0109] Understandably, the credit limit check summary is a multi-dimensional calculation logic based on parameterized configuration. It covers the correlation and constraints between different credit limit types and is the key to realizing dynamic credit limit calculation.

[0110] Specifically, the system extracts a credit limit check summary from the target credit rules. This summary contains multiple elements of the credit limit check, such as the proportional relationship between credit limit types (e.g., cash withdrawal limit is 50% of consumption limit), cumulative restrictions (e.g., the upper limit of the total credit limit), and validity period constraints. The existence of the credit limit check summary enables the system to comprehensively consider various rules and restrictions and dynamically generate the most reasonable actual transaction limit.

[0111] By extracting the quota calculation summary through the above operations, the system can accurately understand the intrinsic relationships and external constraints between quota types based on detailed parameterized configuration, providing clear guidance for subsequent actual transaction quota calculations and improving the accuracy and efficiency of quota management.

[0112] Step S2042: Correct the attributes of each target limit based on the limit check summary to obtain the actual transaction limit.

[0113] Understandably, this step uses mathematical calculations and logical judgments, combined with the target credit rules and credit limit check summary, to correct the target credit limit attributes, ensuring that the actual transaction amount is within the framework of compliance and risk management.

[0114] Specifically, the system uses the rules in the credit limit calculation summary to modify the target credit limit attributes item by item. For example, it adjusts the actual cash withdrawal amount based on the ratio between the consumption limit and the cash withdrawal limit, or adjusts the total available credit limit based on the total credit limit cap. This process may include addition, subtraction, multiplication, and division operations, and may also require logical judgments (such as comparing sizes, checking validity, etc.) to ensure that the final calculated actual transaction amount meets both business needs and risk control standards.

[0115] Through the above operations, and by modifying the attributes based on the summary of the quota calculation, the system can ensure that in scenarios where multiple quotas coexist, the calculation of the actual transaction quota not only follows business rules but also strictly controls risks, avoiding unreasonable quota allocation and waste of resources.

[0116] Through the above embodiments, by introducing the concept of credit limit calculation summaries, the system can dynamically adjust according to different transaction scenarios and rules, ensuring the accuracy of credit limit calculation and meeting diverse transaction needs. When calculating the actual transaction limit, the system strictly adheres to the target credit rules and the restrictions in the credit limit calculation summary, effectively controlling over-credit and potential losses, and improving the security and stability of financial services. The flexible credit limit calculation mechanism can quickly respond to market changes and customer needs, supporting more types of transaction scenarios and promoting business model innovation and expansion.

[0117] In order to execute the transaction event, in an optional implementation, step S204 above further includes:

[0118] Step S2041: In the case of multiple actual transaction amounts, the transaction event is executed with the minimum actual transaction amount.

[0119] Understandably, when a transaction involves multiple credit limit types, the system needs to compare the actual transaction amount calculated for each credit limit type and select the minimum value as the final available credit limit to ensure that the transaction is conducted under the strictest risk control and to avoid overspending or misuse of the credit limit.

[0120] Specifically, during the transaction processing phase, the system may calculate the actual transaction limit for various credit types based on the transaction scenario and credit rules, such as customer-level consumption limit, account-level consumption limit, and cash withdrawal limit. To ensure the security and compliance of the transaction, the system will compare these actual transaction limits and select the minimum value as the final available limit for this transaction, and execute the transaction based on this limit.

[0121] Through the above embodiments, in situations where multiple credit limits coexist, selecting the minimum value as the available credit limit effectively prevents overspending of a single or multiple credit limit types, reducing risks caused by improper rule configuration or misjudgment of transaction scenarios. This ensures transactions are conducted under the strictest credit limit constraints, avoiding situations where credit usage exceeds the prescribed limit, improving operational compliance, and reducing legal risks for financial institutions. Through dynamic calculation and the minimum value selection mechanism, the system can adapt to complex transaction scenarios, quickly respond to changes in transaction characteristics, provide personalized credit limit services, and enhance business flexibility and user experience.

[0122] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0123] This application also provides a transaction apparatus based on event-driven customized messaging. It should be noted that the transaction apparatus based on event-driven customized messaging in this application can be used to execute the transaction method for event-driven customized messaging provided in this application. This apparatus is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0124] The following describes the event-driven customized transaction device provided in the embodiments of this application.

[0125] Figure 3 This is a structural block diagram of an event-driven customized transaction device according to an embodiment of this application. Figure 3 As shown, the device includes:

[0126] The acquisition unit 10 is used to extract the transaction features of a transaction event when a transaction event is detected, and match the transaction features with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios.

[0127] The first processing unit 20 is used to call the corresponding credit limit control unit according to the target transaction scenario to obtain the target credit usage rules. Different credit limit control units include credit usage rules under different transaction scenarios.

[0128] The second processing unit 30 is used to call the corresponding credit limit type unit according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes under different transaction scenarios.

[0129] The calculation unit 40 is used to calculate the actual transaction amount based on the target credit rules and target credit limit attributes, and to execute transaction events based on the actual transaction amount.

[0130] In this embodiment, upon detecting a transaction event, the acquisition unit extracts the transaction characteristics of the event and matches them with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios. The first processing unit calls the corresponding credit limit control unit based on the target transaction scenario to obtain the target credit usage rule. Different credit limit control units include credit limit usage rules for different transaction scenarios. The second processing unit calls the corresponding credit limit type unit based on the target credit usage rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes for different transaction scenarios. The calculation unit calculates the actual transaction amount based on the target credit usage rule and the target credit limit attribute, and executes the transaction event based on the actual transaction amount. Through the implementation of this solution, credit card credit limit management has achieved significant technological progress and business optimization. First, dynamic scenario-based credit limit allocation greatly improves the utilization rate of credit limit resources. By adjusting the credit limit allocation in real time according to different transaction characteristics, users can obtain credit support that better meets their needs in various transaction scenarios. Second, the introduction of the parameterized rule factor engine enables risk control strategies to respond quickly to market changes, reduce the scenario misjudgment rate, and further improve the accuracy of resource allocation. Finally, the transaction event-driven quota control unit design not only enhances the system's flexibility but also significantly shortens the response time for quota calculation and control, improves the user experience, and provides financial institutions with a more efficient and secure means of quota management, solving the problem of insufficient resource utilization caused by the fixed quota allocation mechanism in existing technologies.

[0131] To determine the aforementioned target transaction scenario, in one optional implementation, the acquisition unit includes:

[0132] The first acquisition module is used to extract the transaction object, transaction method, transaction amount and transaction type of the transaction event to obtain the transaction characteristics;

[0133] The first processing module is used to match transaction characteristics with various preset rule sets;

[0134] The first determination module is used to determine the transaction scenario corresponding to the set of preset rules that have been matched as the target transaction scenario.

[0135] To determine the aforementioned target information rules, in one optional implementation, the first processing unit includes:

[0136] The first query module is used to query the first mapping relationship based on the target transaction scenario to obtain the target control unit. The first mapping relationship is the mapping relationship between the transaction scenario and the quota control unit.

[0137] The second acquisition module is used to extract the credit limit usage rules from the target management unit to obtain the first credit limit rule;

[0138] The second processing module is used to match the transaction features with the first credit rules, and to filter the matched first credit rules through parameterized checks and priority filtering to obtain the target credit rules.

[0139] To ensure the accuracy of the aforementioned target information rules, in one optional implementation, the second processing module includes:

[0140] The first processing submodule is used to verify the feature parameters of the transaction features according to the check conditions and check thresholds of each first credit rule that has been matched;

[0141] The second processing submodule is used to determine whether each first-user rule can coexist if the verification passes by using preset code parameters.

[0142] The third processing submodule is used to determine each first credit rule as the target credit rule when the first credit rules can coexist.

[0143] The fourth processing submodule is used to determine the first credit rule with the highest priority as the target credit rule when the first credit rules cannot coexist.

[0144] To determine the aforementioned target quota attributes, in one optional implementation, the second processing unit includes:

[0145] The second query module is used to query the second mapping relationship according to the target credit rule to obtain the target credit limit unit. The second mapping relationship is the mapping relationship between the credit limit rule and the credit limit type unit.

[0146] The third acquisition module is used to extract the quota attribute from the target quota unit to obtain the first quota attribute;

[0147] The first calculation module is used to calculate the actual value of the first credit limit attribute according to the target credit rule, so as to obtain the target credit limit attribute.

[0148] In order to determine the user's actual transaction amount, in one optional implementation, the above-mentioned calculation unit includes:

[0149] The fourth acquisition module is used to extract a credit limit check summary from the target credit rule, wherein the credit limit check summary is used to characterize the restriction relationship between different types of credit limit attributes;

[0150] The second calculation module is used to correct each of the target limit attributes based on the limit check summary to obtain the actual transaction limit.

[0151] To enable the execution of transaction events, in one optional implementation, the computing unit further includes:

[0152] The third processing module is used to execute a transaction event by taking the minimum actual transaction amount when there are multiple actual transaction amounts.

[0153] The aforementioned event-driven customized transaction device includes a processor and a memory. The acquisition unit, first processing unit, second processing unit, and calculation unit are all stored as program units in the memory. The processor executes these program units stored in the memory to achieve the corresponding functions. All of the above modules reside in the same processor; alternatively, the modules may be located in different processors in any combination.

[0154] A processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and resource utilization can be improved by adjusting kernel parameters.

[0155] The memory may include non-permanent 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, and the memory includes at least one memory chip.

[0156] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to execute the event-driven customized credit transaction method.

[0157] Specifically, event-driven customized credit transaction methods include:

[0158] Step S201: When a transaction event is detected, the transaction features of the transaction event are extracted, and the transaction features are matched with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios.

[0159] Step S202: Based on the target transaction scenario, call the corresponding credit limit control unit to obtain the target credit usage rules. Different credit limit control units include credit limit usage rules under different transaction scenarios.

[0160] Step S203: Call the corresponding credit limit type unit according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes under different transaction scenarios.

[0161] Step S204: Calculate the actual transaction amount based on the target credit rules and target credit limit attributes, and execute the transaction event based on the actual transaction amount.

[0162] This invention provides a processor for running a program, wherein the program executes the event-driven customized credit transaction method described above.

[0163] Specifically, event-driven customized credit transaction methods include:

[0164] Step S201: When a transaction event is detected, the transaction features of the transaction event are extracted, and the transaction features are matched with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios.

[0165] Step S202: Based on the target transaction scenario, call the corresponding credit limit control unit to obtain the target credit usage rules. Different credit limit control units include credit limit usage rules under different transaction scenarios.

[0166] Step S203: Call the corresponding credit limit type unit according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes under different transaction scenarios.

[0167] Step S204: Calculate the actual transaction amount based on the target credit rules and target credit limit attributes, and execute the transaction event based on the actual transaction amount.

[0168] This invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps:

[0169] Step S201: When a transaction event is detected, the transaction features of the transaction event are extracted, and the transaction features are matched with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios.

[0170] Step S202: Based on the target transaction scenario, call the corresponding credit limit control unit to obtain the target credit usage rules. Different credit limit control units include credit limit usage rules under different transaction scenarios.

[0171] Step S203: Call the corresponding credit limit type unit according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes under different transaction scenarios.

[0172] Step S204: Calculate the actual transaction amount based on the target credit rules and target credit limit attributes, and execute the transaction event based on the actual transaction amount.

[0173] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps:

[0174] Step S201: When a transaction event is detected, the transaction features of the transaction event are extracted, and the transaction features are matched with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios.

[0175] Step S202: Based on the target transaction scenario, call the corresponding credit limit control unit to obtain the target credit usage rules. Different credit limit control units include credit limit usage rules under different transaction scenarios.

[0176] Step S203: Call the corresponding credit limit type unit according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes under different transaction scenarios.

[0177] Step S204: Calculate the actual transaction amount based on the target credit rules and target credit limit attributes, and execute the transaction event based on the actual transaction amount.

[0178] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0179] 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.

[0180] 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.

[0181] 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.

[0182] 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.

[0183] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0184] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0185] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by 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 tape, 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.

[0186] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0187] 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.

[0188] As can be seen from the above description, the embodiments of this application achieve the following technical effects:

[0189] 1) The event-driven customized credit transaction method of this application first extracts the transaction characteristics of the transaction event upon detecting a transaction event, and matches these characteristics with a transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios. Then, the corresponding credit limit management unit is called according to the target transaction scenario to obtain the target credit rule. Different credit limit management units include credit limit rules for different transaction scenarios. Next, the corresponding credit limit type unit is called according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes for different transaction scenarios. Finally, the actual transaction amount is calculated based on the target credit rule and the target credit limit attribute, and the transaction event is executed based on the actual transaction amount. Through the implementation of this solution, credit card credit limit management has achieved significant technological progress and business optimization. First, dynamic scenario-based credit limit allocation greatly improves the utilization rate of credit limit resources. By adjusting the credit limit allocation in real time according to different transaction characteristics, users can obtain credit support that better meets their needs in various transaction scenarios. Secondly, the introduction of the parameterized rule factor engine enables risk control strategies to respond quickly to market changes, reduce the misjudgment rate of scenarios, and further improve the accuracy of resource allocation. Finally, the transaction event-driven quota control unit design not only enhances the system's flexibility but also significantly shortens the response time for quota calculation and control, improving user experience. It also provides financial institutions with a more efficient and secure means of quota management, solving the problem of insufficient resource utilization caused by the fixed quota allocation mechanism in existing technologies.

[0190] 2) The event-driven customized credit transaction device of this application, upon detecting a transaction event, extracts the transaction characteristics of the event and matches them with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios. The first processing unit calls the corresponding credit limit control unit according to the target transaction scenario to obtain the target credit rule. Different credit limit control units include credit limit rules for different transaction scenarios. The second processing unit calls the corresponding credit limit type unit according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes for different transaction scenarios. The calculation unit calculates the actual transaction amount based on the target credit rule and the target credit limit attribute, and executes the transaction event based on the actual transaction amount. Through the implementation of this solution, credit card credit limit management has achieved significant technological progress and business optimization. First, dynamic scenario-based credit limit allocation greatly improves the utilization rate of credit limit resources. By adjusting the credit limit allocation in real time according to different transaction characteristics, users can obtain credit support that better meets their needs in various transaction scenarios. Secondly, the introduction of the parameterized rule factor engine enables risk control strategies to respond quickly to market changes, reduce the misjudgment rate of scenarios, and further improve the accuracy of resource allocation. Finally, the transaction event-driven quota control unit design not only enhances the system's flexibility but also significantly shortens the response time for quota calculation and control, improving user experience. It also provides financial institutions with a more efficient and secure means of quota management, solving the problem of insufficient resource utilization caused by the fixed quota allocation mechanism in existing technologies.

[0191] The above description is merely a preferred embodiment of this application and is not intended to limit 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 protection scope of this application.

Claims

1. A transaction method based on event-driven customized credit information, characterized in that, include: Upon detecting a transaction event, the transaction characteristics of the transaction event are extracted, and the transaction characteristics are matched with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios. The corresponding credit limit control unit is invoked according to the target transaction scenario to obtain the target credit usage rules. Different credit limit control units include credit usage rules under different transaction scenarios. The corresponding credit limit type unit is called according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes under different transaction scenarios. The actual transaction amount is calculated based on the target credit rule and the target credit limit attribute, and the transaction event is executed based on the actual transaction amount.

2. The method according to claim 1, characterized in that, Extracting transaction features from the transaction events and matching these features with the transaction routing unit to determine the target transaction scenario includes: Extract the transaction object, transaction method, transaction amount, and transaction type of the transaction event to obtain the transaction characteristics; The transaction characteristics are matched with each of the preset rule sets; The transaction scenario corresponding to the set of preset rules that match the target transaction scenario is determined.

3. The method according to claim 2, characterized in that, Based on the target transaction scenario, the corresponding credit limit control unit is invoked to obtain the target credit rules, including: Based on the target transaction scenario, the first mapping relationship is queried to obtain the target control unit. The first mapping relationship is the mapping relationship between the transaction scenario and the quota control unit. Extract the credit limit usage rules from the target management unit to obtain the first credit usage rule; The transaction features are matched with the first credit rule, and the matched first credit rule is filtered through parameterized checks and priority filtering to obtain the target credit rule.

4. The method according to claim 3, characterized in that, The first matching credit rule is filtered through parameterized checks and priority filtering to obtain the target credit rule, including: The feature parameters of the transaction feature are verified according to the check conditions and check thresholds of each of the first credit rules that are matched. If the verification passes, the pre-defined code parameters are used to determine whether each of the first application rules can coexist. When all the first credit rules can coexist, each of the first credit rules is determined as the target credit rule; If the first credit rules cannot coexist, the first credit rule with the highest priority is determined as the target credit rule.

5. The method according to claim 1, characterized in that, Based on the target credit rule, the corresponding credit limit type unit is invoked to obtain the target credit limit attributes, including: The target credit limit unit is obtained by querying the second mapping relationship according to the target credit rule. The second mapping relationship is the mapping relationship between the credit limit rule and the credit limit type unit. Extract the credit limit attribute from the target credit limit unit to obtain the first credit limit attribute; The actual value of the first credit limit attribute is calculated based on the target credit rule to obtain the target credit limit attribute.

6. The method according to claim 5, characterized in that, Calculating the actual transaction amount based on the target credit rules and the target credit limit attributes includes: Extract the credit limit check summary from the target credit rule, the credit limit check summary is used to characterize the restriction relationship between different types of credit limit attributes; Based on the quota check summary, each of the target quota attributes is corrected to obtain the actual transaction quota.

7. The method according to claim 1, characterized in that, Execute the transaction event based on the actual transaction amount, including: If there are multiple actual transaction amounts, the transaction event is executed with the minimum value of the actual transaction amounts.

8. A transaction device based on event-driven customized messaging, characterized in that, The device includes: The acquisition unit is used to extract the transaction features of a transaction event when a transaction event is detected, and match the transaction features with the transaction routing unit to determine the target transaction scenario. The transaction routing unit includes a set of preset rules corresponding to different transaction scenarios. The first processing unit is used to call the corresponding credit limit control unit according to the target transaction scenario to obtain the target credit usage rules. Different credit limit control units include credit usage rules under different transaction scenarios. The second processing unit is used to call the corresponding credit limit type unit according to the target credit rule to obtain the target credit limit attribute. Different credit limit type units include credit limit attributes under different transaction scenarios. The calculation unit is used to calculate the actual transaction amount based on the target credit rule and the target credit limit attribute, and to execute the transaction event based on the actual transaction amount.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising methods for performing any one of claims 1 to 7.

Images