Credit card transaction data processing method and device and computer readable storage medium

Abstract

The invention provides a credit card transaction data processing method and device and a computer readable storage medium. Receiving a transaction request, and determining a transaction-level account type code according to element information of the transaction request; determining whether the transaction request is a credit transaction based on the transaction-level account type code; when the transaction request is a credit transaction, performing first processing on the credit transaction to obtain a first processing result; under the condition that the transaction request is not the credit transaction, determining that the transaction request is a debit transaction, and performing second processing on the debit transaction to obtain a second processing result; in the bill period, third processing is carried out on the first processing result and the second processing result, bill hierarchy data is obtained and generated, and the bill hierarchy data is used for real-time query and reflection of principal, interest and cost of each transaction. According to the scheme, the problem of limitation of credit card transaction processing, including relatively low risk management capability and relatively low data utilization rate, is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a credit card transaction data processing method, a credit card transaction data processing device and a computer readable storage medium. BACKGROUND

[0002] The credit card industry is undergoing digital transformation, and banks strive to provide personalized services through deepening consumer ecosystem and intelligent risk control technology. However, the traditional account system is static and product-centered, which is difficult to adapt to market changes and fine operation needs, limiting differentiated services based on user portraits and scenarios.

[0003] The existing credit card account processing method has defects: the account creation strategy is rigid and cannot adapt to high-frequency transactions; data silos make it difficult to share data between different businesses; real-time differentiated pricing based on transaction details cannot be achieved, affecting risk assessment and revenue optimization. These limitations hinder banks to improve service level and risk management capability. SUMMARY

[0004] The main purpose of the present application is to provide a credit card transaction data processing method, a credit card transaction data processing device and a computer readable storage medium, to at least solve the problem of limitations in credit card transaction processing in the prior art, including low risk management capability and low data utilization.

[0005] In order to achieve the above purpose, according to one aspect of the present application, a credit card transaction data processing method is provided, comprising: receiving a transaction request, and determining a transaction level account type code according to the element information of the transaction request; determining whether the transaction request is a credit transaction based on the transaction level account type code; in the case that the transaction request is the credit transaction, performing a first processing on the credit transaction to obtain a first processing result; in the case that the transaction request is not the credit transaction, determining that the transaction request is a debit transaction, and performing a second processing on the debit transaction to obtain a second processing result; within a billing cycle, performing a third processing on the first processing result and the second processing result to obtain generated billing level data, the billing level data being used for real-time query and reflecting the principal, interest and fee of each transaction, the third processing including interest settlement, interest account derivation creation and billing aggregation calculation.

[0006] Optionally, receiving a transaction request and determining a transaction-level account type code according to element information of the transaction request comprises: receiving the transaction request and extracting the element information of the transaction request by using a message parsing engine, the element information comprising management account information, scenario information and time information; executing a parameterized configuration matching rule according to the element information to obtain a transaction type of the transaction request; and determining the transaction-level account type code based on the transaction type.

[0007] Optionally, after determining the transaction-level account type code based on the transaction type, the method further comprises: creating a transaction-level account according to the transaction-level account type code, the transaction-level account being used to store attribute information, the attribute information comprising management account basic information, balance type, pricing rule, account aggregation mode, creation time and parent account number.

[0008] Optionally, in the case where the transaction request is the credit transaction, performing first processing on the credit transaction to obtain a first processing result comprises: in the case where the transaction request is the credit transaction, performing precise or fuzzy matching on the credit transaction based on first information to obtain an original transaction record, the first information at least comprising a serial number and a transaction date; in the case where the original transaction record represents that the credit transaction is a return transaction, performing first deduction on an original transaction-level account to obtain a first deduction result; in the case where the original transaction record represents that the credit transaction is a dispute account adjustment, performing second deduction according to an associated account at the time of dispute registration to obtain a second deduction result; wherein the first processing result comprises the first deduction result and the second deduction result.

[0009] Optionally, after performing precise or fuzzy matching on the transaction request based on first information, the method further comprises: in the case where the transaction request cannot be matched to the original transaction record, selecting a deduction rule set according to an account overdue state; generating a dynamic priority based on the deduction rule set, an overdue day number and a remaining principal proportion; and performing third deduction according to the dynamic priority to obtain a third deduction result.

[0010] Optionally, the transaction request is determined as a debit transaction, and the second processing is performed on the debit transaction to obtain a second processing result, including: in the case that the transaction request is determined as a debit transaction, checking the overpayment account state and generating overpayment cancellation information based on the overpayment balance; based on the overpayment cancellation information, performing dynamic pricing processing on the remaining transaction finance to obtain a dynamically priced interest rate parameter; based on the dynamically priced interest rate parameter and the transaction type, setting an account creation strategy, and registering the debit transaction in the corresponding transaction-level account according to the account creation strategy, and updating the account balance and interest to obtain updated transaction-level account information; wherein the second processing result includes the overpayment cancellation information, the dynamically priced interest rate parameter, and the updated transaction-level account information.

[0011] Optionally, based on the dynamically priced interest rate parameter and the transaction type, the account creation strategy is set, including: based on the dynamically priced interest rate parameter and the transaction type, determining the frequency risk information of the debit transaction; in the case that the frequency risk information of the debit transaction is high-frequency low-risk transaction, setting a first account creation strategy, the first account creation strategy is a strategy of merging daily transactions of the same type to the same account in a daily summary mode; in the case that the frequency risk information of the debit transaction is low-frequency high-risk transaction, setting a second account creation strategy, the second account creation strategy is a strategy of independently building an account for each single order; wherein the account creation strategy includes the first account creation strategy and the second account creation strategy, and the execution of the account creation strategy is realized by parameterized configuration.

[0012] Optionally, in a billing cycle, the first processing result and the second processing result are subjected to third processing to obtain billing level data, including: in the billing cycle, based on the first processing result and the second processing result, obtaining the transaction-level accounts that are not cleared; obtaining the current effective interest rate, the balance and the interest calculation days, and calculating the interest for each of the transaction-level accounts that are not cleared according to the current effective interest rate, the balance and the interest calculation days; after the interest calculation, creating an interest derivative transaction-level account, and creating a compound interest account type for the interest generated by the interest derivative transaction-level account, calculating the cumulative overdue interest to obtain an interest processing result; based on the interest processing result, performing multi-dimensional aggregation calculation on all the transaction-level accounts that are not cleared in the current cycle to obtain the billing level data.

[0013] According to another aspect of the present application, a credit card transaction data processing apparatus is provided, comprising: a first determining unit configured to receive a transaction request and determine a transaction level account type code according to element information of the transaction request; a second determining unit configured to determine whether the transaction request is a credit transaction based on the transaction level account type code; a first processing unit configured to, in the case that the transaction request is the credit transaction, perform a first processing on the credit transaction to obtain a first processing result; a second processing unit configured to, in the case that the transaction request is not the credit transaction, determine that the transaction request is a debit transaction and perform a second processing on the debit transaction to obtain a second processing result; and a third processing unit configured to, in a billing cycle, perform a third processing on the first processing result and the second processing result to obtain billing level data, the billing level data being used for real-time query and reflecting principal, interest and fees of each transaction, the third processing including interest settlement, interest account derivation creation and billing aggregation calculation.

[0014] According to still another aspect of the present application, a computer readable storage medium is provided, comprising a stored program, wherein the program, when executed, controls a device in which the computer readable storage medium is located to perform any of the credit card transaction data processing methods.

[0015] By applying the technical solution of the present application, a transaction request is received, and a transaction level account type code is determined according to element information of the transaction request; whether the transaction request is a credit transaction is determined based on the transaction level account type code; in the case that the transaction request is the credit transaction, a first processing is performed on the credit transaction to obtain a first processing result; in the case that the transaction request is not the credit transaction, it is determined that the transaction request is a debit transaction, and a second processing is performed on the debit transaction to obtain a second processing result; and in a billing cycle, a third processing is performed on the first processing result and the second processing result to obtain billing level data, the billing level data being used for real-time query and reflecting principal, interest and fees of each transaction, the third processing including interest settlement, interest account derivation creation and billing aggregation calculation. In this solution, by dynamically determining the transaction level account type code, the transaction nature is intelligently determined, efficient and accurate processing of credit and debit transactions is achieved, and error operations are reduced. In particular, in a billing cycle, the first processing result and the second processing result are integrated, interest settlement is performed, an interest account is derived and created, and finally, detailed billing level data is aggregated and calculated. This data not only reflects principal, interest and fee information of each transaction in real time, but also supports instant query by the user, greatly improving the transparency of bank account processing and customer satisfaction. In particular, by fine management and full-link closed loop of data, the operation efficiency and risk management capability of the bank are optimized, thereby solving the problems of limitations in credit card transaction processing in the prior art, including low risk management capability and low data utilization rate. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which form a part of the specification, are included to provide a further understanding of the application and are incorporated herein in their entirety. The illustrations are shown in the drawings are provided to explain the application and are not intended to limit the application in any way. In the drawings:

[0017] Figure 1 A hardware structure block diagram of a mobile terminal for performing a credit card transaction data processing method according to an embodiment of the present application is shown;

[0018] Figure 2 A flowchart of a credit card transaction data processing method according to an embodiment of the present application is shown;

[0019] Figure 3 A flowchart of a specific credit card transaction data processing method according to an embodiment of the present application is shown;

[0020] Figure 4 A flowchart of initialization processing of a new transaction request of a specific credit card transaction data processing method according to an embodiment of the present application is shown;

[0021] Figure 5 A flowchart of closed loop processing of a billing cycle of a specific credit card transaction data processing method according to an embodiment of the present application is shown;

[0022] Figure 6 A structure block diagram of a credit card transaction data processing apparatus according to an embodiment of the present application is shown.

[0023] In the above drawings, the following reference signs are used:

[0024] 102, processor; 104, memory; 106, transmission device; 108, input / output device. DETAILED DESCRIPTION

[0025] It should be noted that the embodiments and features of the embodiments in the present application can be combined with each other without conflict. The technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the present application.

[0026] In order 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 described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the present application.

[0027] It should be noted that the terms "first", "second", and the like in the description and in the claims of the present application and above-described accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances so that the embodiments of the present application described herein can be implemented. In addition, the terms "comprise" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device comprising a list of steps or units does not necessarily limit to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0028] As introduced in the background, the existing credit card account processing method in the prior art has defects, which hinders the bank to improve the service level and risk management capability. In order to solve the problem of the limitation of the credit card transaction processing in the prior art, including the lower risk management capability and the lower data utilization, the embodiments of the present application provide a credit card transaction data processing method, a credit card transaction data processing device and a computer readable storage medium.

[0029] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the accompanying drawings in the embodiments of the present application.

[0030] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking the running on the mobile terminal as an example, Figure 1 is a hardware structure block diagram of a mobile terminal of a credit card transaction data processing method of the embodiments of the present application. As shown in Figure 1 , the mobile terminal can include one or more (only one is shown in Figure 1 ) processor 102 (the processor 102 can include but not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the above-mentioned mobile terminal can further include a transmission device 106 for communication function and an input and output device 108. Those skilled in the art can understand that Figure 1 the structure shown is only schematic, which does not limit the structure of the above-mentioned mobile terminal. For example, the mobile terminal can further include more or less components than those shown in Figure 1 , or have a different configuration from Figure 1 .

[0031] The memory 104 can be used to store computer programs, such as software programs of application software and modules, such as the computer program corresponding to the credit card transaction data processing method of the embodiments of the present application. The processor 102 can execute various functional applications and data processing, i.e., implement the above method, by running the computer programs stored in the memory 104. The memory 104 can include a high-speed random access memory, and can further include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 104 can further include memories remotely arranged with respect to the processor 102, which can be connected to the mobile terminal through a network. Examples of the above network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. The transmission device 106 is used to receive or send data via a network. The specific examples of the above network can include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device 106 includes a network adapter (NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet in a wireless manner.

[0032] In the embodiments, a credit card transaction data processing method running on a mobile terminal, a computer terminal or a similar computing device is provided. It should be noted that the steps shown in the flowchart of 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 can be executed in an order different from that herein.

[0033] Figure 2 is a flowchart of the credit card transaction data processing method according to the embodiments of the present application. As shown in Figure 2 , the method includes the following steps:

[0034] In step S201, a transaction request is received, and a transaction level account type code is determined according to the element information of the above transaction request;

[0035] Specifically, a transaction request can be received, which can be a credit card transaction instruction initiated by a user through various channels such as online payment, ATM, etc. After receiving the transaction request, the transaction request contained therein is parsed, and the element information is extracted, which usually includes management account information (such as the basic information of the customer, the type and status of the credit card), scene information (such as the type of merchant where the transaction occurs, the region and channel of the transaction), and time information (such as the specific date of the transaction and the clearing date). Based on these element information, the transaction level account type code is determined, which is a kind of code for defining the financial properties of the account balance composition, which can distinguish different balance types such as principal, fee, interest, etc. in detail, and can also be further refined according to the scene classification, such as distinguishing transactions in different scenarios such as ordinary consumption, medical consumption or education installment.

[0036] The key to this process is the accurate classification of the transaction request, ensuring that each transaction can be recorded in the most appropriate transaction level account, thereby laying a solid foundation for subsequent steps such as loan transaction processing, debit transaction processing, interest settlement and bill aggregation calculation within the billing cycle, and finally generating detailed and accurate bill level data to support real-time query and reflect the principal, interest and fee information of each transaction. Such design can greatly improve the accuracy and efficiency of data processing, and also makes it possible to achieve more refined credit card account management.

[0037] Step S202, determining whether the transaction request is a loan transaction based on the transaction level account type code;

[0038] Specifically, the process of determining whether the transaction request is a loan transaction based on the transaction level account type code is essentially an intelligent identification of the nature of the transaction. The transaction level account type code contains detailed attributes of the transaction, such as transaction category (principal, fee, interest, etc.), scene classification (daily consumption, education installment, medical special purpose, etc.), and financial property information. When the transaction request is received, it will be determined whether the transaction belongs to a loan transaction or a debit transaction according to the preset information in the transaction level account type code. Loan transactions usually refer to those that increase the balance of the credit card account and are considered as income, such as the customer's repayment, refund or bank's adjustment of accounts, etc. On the contrary, debit transactions are those that reduce the account balance and are considered as expenses, such as consumption, cash withdrawal, etc.

[0039] By analyzing the transaction type description in the transaction-level account type code, the nature of the transaction request can be determined, and the corresponding processing logic can be decided. That is, if it is a credit transaction, it enters the credit transaction processing flow; otherwise, it enters the debit transaction processing flow. This determination logic helps to efficiently and accurately divert and process various transaction requests, ensuring that credit and debit transactions are properly processed according to their respective business rules and processes, thereby improving the operational efficiency and accuracy of the entire accounting system.

[0040] Step S203: If the transaction request is a credit transaction, perform a first processing on the credit transaction to obtain a first processing result.

[0041] Specifically, when a transaction request is determined to be a credit transaction, this type of transaction undergoes initial processing, ultimately yielding a first processing result. Common scenarios for credit transactions include customer repayments, bank refunds, and account adjustments due to disputes. Their common characteristic is that they tend to reduce the outstanding balance in the account or increase the available credit limit. After step S203, the credit transaction is effectively processed, and the balance in the transaction account is correctly updated, resulting in a first processing result containing information such as account balance changes and transaction processing status. The first processing result reflects the latest account status after the credit transaction processing, providing an accurate basis for subsequent billing generation, data analysis, and customer service.

[0042] Step S204: If the transaction request is not a credit transaction, determine that the transaction request is a debit transaction, and perform a second processing on the debit transaction to obtain a second processing result;

[0043] Specifically, when a transaction request is determined not to fall under the category of a credit transaction—that is, the request does not involve repaying debt or increasing the available credit limit—it is automatically identified as a debit transaction. Debit transactions are those that increase the outstanding balance of an account; common examples include consumers using credit cards for shopping, cash withdrawals, and other forms of spending. After step S204, the debit transaction processing is complete, and the resulting second processing result includes detailed information about the debit transaction, such as the processed account balance, the applicable interest rate level, and any changes to overpayments. This information will be used for subsequent billing and other financial management activities. This refined debit transaction processing not only improves the efficiency of account management but also strengthens risk control capabilities.

[0044] Step S205: During the billing cycle, the first processing result and the second processing result are subjected to a third processing to generate billing-level data. The billing-level data is used to query and reflect the principal, interest and fees of each transaction in real time. The third processing includes interest settlement, interest account creation and bill aggregation calculation.

[0045] Specifically, a third processing step is performed within the credit card billing cycle. This third step integrates and calculates the results of the first processing (for credit transactions) and the second processing (for debit transactions) to generate billing-level data. This billing-level data is a highly aggregated and analyzed result that not only reflects the overall financial status of the credit card account within the billing cycle but also records detailed principal, interest, and fee information for each transaction, facilitating real-time access to and understanding of customer account activity. The third processing step includes interest settlement, interest account creation, and aggregated billing calculations. Through this series of third processing steps, financial settlement within the billing cycle is completed, generating comprehensive billing-level data. This data not only reflects all of the customer's transaction activities within the cycle but also includes refined interest and fee calculations, as well as dynamic pricing and risk management strategies for different transaction scenarios. This approach ensures the accuracy and transparency of billing data while significantly improving the efficiency of billing management and customer experience.

[0046] This embodiment dynamically determines the transaction-level account type code and intelligently judges the nature of the transaction, achieving efficient and accurate processing of credit and debit transactions and reducing erroneous operations. Especially within the billing cycle, by integrating the first and second processing results, interest is calculated, interest accounts are created, and finally, detailed billing-level data is aggregated and calculated. This data not only reflects the principal, interest, and fee information of each transaction in real time, but also supports users' instant queries, greatly improving the transparency of bank accounting and customer satisfaction. In particular, through refined management and a closed-loop data chain, the bank's operational efficiency and risk management capabilities are optimized, thereby solving the limitations of existing credit card transaction processing technologies, including low risk management capabilities and low data utilization.

[0047] In the specific implementation process, receiving a transaction request and determining the transaction-level account type code based on the element information of the transaction request includes: receiving the transaction request and using a message parsing engine to extract the element information of the transaction request, the element information including management account information, scenario information and time information; executing the parameterized configuration matching rules based on the element information to obtain the transaction type of the transaction request; and determining the transaction-level account type code based on the transaction type.

[0048] The above process further refines the process of receiving transaction requests and determining the transaction-level account type code. This process aims to ensure that transaction requests can be accurately and efficiently classified, and appropriate transaction-level accounts can be created accordingly. Specifically, first, credit card transaction requests are received from various channels (such as POS terminals, ATMs, online banking, mobile applications, etc.). These requests are usually sent in the form of electronic messages, which include complete transaction information. The message parsing engine automatically reads and decodes these electronic messages, extracting key element information for subsequent transaction processing. This element information mainly includes three core parts: management account information, scenario information, and time information. Management account information includes the customer's basic information, credit card product type, account status, etc. Management account information is an important basis for identifying customer identity and account, and is also the foundation for transaction processing. Scenario information covers the environmental details in which the transaction occurred, such as merchant type, transaction location, and transaction channel (online or offline). Scenario information is crucial for understanding and classifying transactions because it determines the specific attributes of the transaction and the corresponding management measures. Time information, including timestamps such as transaction date and settlement date, is used to track the timeline of transactions. This is crucial for accounting and risk management, as different time periods may involve different interest rates and compliance requirements. Next, a set of pre-defined, parameterized matching rules is used to analyze the extracted data. These rules are designed to differentiate between different types of transactions, such as spending, transfers, cash withdrawals, installment payments, and repayments. By executing these rules, transaction information can be analyzed from multiple dimensions, including transaction context, account status, and time, accurately determining the transaction category and laying the foundation for subsequent differentiated processing.

[0049] Once the transaction type is determined, a transaction-level account type code is further established based on this type. The transaction-level account type code describes the financial attributes of the transaction-level account balance components, containing detailed classification information about the transaction. For example, for a consumer transaction, the code might include subcategories such as "consumption principal" and "consumption interest"; for an installment payment transaction, the code might include more specific subcategories such as "installment principal," "installment interest," and "installment fees." This coding system enables independent management of different transaction types. Each transaction-level account type code corresponds to a specific transaction type and scenario, allowing for refined pricing, interest calculation, and accounting. This not only improves the accuracy and efficiency of transaction processing but also provides technical support for implementing differentiated services based on user profiles and scenario variables, ensuring that more personalized financial service strategies can be implemented according to different customers' credit status and transaction scenarios.

[0050] By employing a message parsing engine to accurately extract management account information, scenario information, and time information from transaction requests, and combining this with parameterized matching rules to determine the transaction type, and finally establishing a transaction-level account type code based on the transaction type, this series of processes significantly improves the efficiency and accuracy of credit card transaction data processing. First, it enables rapid and accurate identification and classification of transactions, laying the foundation for subsequent refined management and personalized services. Second, the determination of transaction-level account type codes enables dynamic and scenario-based management of transactions, supporting real-time differentiated pricing and risk assessment, enhancing the flexibility and responsiveness of financial services. Finally, it ensures the integrity and traceability of transaction data, providing detailed and accurate information support for bill generation, dispute resolution, and compliance audits, improving the transparency of the overall accounting system and customer satisfaction. This embodiment ensures the correct classification of transactions and the accurate establishment of transaction-level accounts, laying a solid data foundation for subsequent credit and debit transaction processing and bill generation.

[0051] Furthermore, after determining the transaction-level account type code based on the above transaction type, the above method also includes: creating a transaction-level account according to the above transaction-level account type code, wherein the transaction-level account is used to store attribute information, including basic information of the management account, balance type, pricing rules, account aggregation method, creation time, and parent account number.

[0052] Specifically, to ensure smooth subsequent processing and accurate data management, a brand-new transaction-level account is created based on the established transaction-level account type code. This step ensures that each transaction is recorded and managed in a specific account with defined attributes. For example, a consumer transaction requires a transaction-level account labeled "Consumer Principal," while a portion of an installment payment requires an account coded "Installment Principal." This classification and account creation mechanism enables the system to precisely track and manage various types of transactions.

[0053] The created transaction-level account stores several key attributes to meet the management needs of different transaction types. These attributes include basic management account information, balance type, pricing rules, account aggregation method, creation time, and parent account number. Basic management account information includes basic customer information, account status, and detailed information about credit card products. This is crucial information linking to higher-level management accounts, ensuring consistency and coherence between the transaction-level account and the customer's overall account. The balance type clarifies the specific balance attributes in the transaction-level account, such as principal, interest, fees, or compound interest, helping to identify and process balances of different natures. Pricing rules are the current effective interest rate and other pricing-related information in the transaction-level account. These rules determine how interest is calculated for transactions, supporting real-time differentiated pricing based on merchant information, time period, and risk score, reflecting the characteristics of refined management. The account aggregation method specifies the rules for aggregating transaction-level accounts to higher-level accounts (such as statistical accounts and billing accounts), such as daily aggregation, monthly aggregation, or full aggregation mode, ensuring different levels of account management and financial reporting needs. The creation time records the creation date of the transaction-level account, which helps with subsequent billing cycle management and the retrospective analysis of transaction occurrences. The parent account number is used to establish a link between the transaction-level account and its managing account or other higher-level accounts, ensuring data consistency and traceability, which is particularly important when dealing with interest-derived accounts.

[0054] After determining the transaction-level account type code, a corresponding transaction-level account is created based on this code, storing comprehensive attribute information including basic account information, balance type, pricing rules, account aggregation method, creation time, and parent account number. This significantly enhances the accuracy and flexibility of credit card transaction data processing. On the one hand, by storing rich attribute information, deep classification and management of transaction data are achieved, ensuring that each transaction can be accurately identified and tracked, guaranteeing data integrity and traceability in terms of principal, interest, and fees. On the other hand, the parameterized configuration of pricing rules and account aggregation methods allows banks to optimize account aggregation strategies while implementing real-time differentiated pricing based on factors such as merchant, time period, and risk score. This balances business needs with the rational use of system resources, improving the overall efficiency of accounting processing. Furthermore, recording the creation time and parent account number of the transaction-level account provides strong support for subsequent bill generation and data analysis, ensuring the transparency and consistency of financial information, thereby improving customer service quality and risk control capabilities. In summary, this embodiment effectively promotes the scenario-based response speed, refined operational capabilities, and data integration level of credit card business.

[0055] In some embodiments of this application, when the transaction request is a credit transaction, the credit transaction is subjected to a first processing to obtain a first processing result, including: when the transaction request is a credit transaction, performing precise or fuzzy matching on the credit transaction based on first information to obtain an original transaction record, wherein the first information includes at least a serial number and a transaction date; when the original transaction record indicates that the credit transaction is a return transaction, performing a first reversal on the original transaction-level account to obtain a first reversal result; when the original transaction record indicates that the credit transaction is a disputed reconciliation, performing a second reversal according to the associated account at the time of dispute registration to obtain a second reversal result; wherein the first processing result includes the first reversal result and the second reversal result.

[0056] Specifically, when a received transaction request is a credit transaction, the system first searches the database for a matching original transaction record based on the provided initial information (at least the transaction number and transaction date). This initial information acts as a unique identifier or key piece of information for the transaction, used to locate previous debit transactions or existing liabilities. If sufficient information, such as the transaction number, is provided, an exact match will be attempted; if information is missing, a fuzzy match will be performed based on the transaction date and other relevant information to find the correct transaction record as much as possible.

[0057] If the credit transaction is a return transaction, a first reversal is performed on the original transaction-level account. This means that the return amount is deducted from the account previously recorded for the purchase or transaction, and the account balance is updated to ensure accounting accuracy. For example, if a customer buys a product online and pays for it, then chooses to return it, the return amount will be deducted from the transaction-level account from which the payment was made. This operation is called the first reversal, and the result is the first reversal result. Its purpose is to restore the account balance change caused by the return.

[0058] When a credit transaction is initiated due to a disputed adjustment—that is, when an adjustment to funds is required due to a dispute over a transaction—a second reversal is made according to the related accounts established at the time of dispute registration. These related accounts refer to specific transaction-level accounts that have been marked or identified as objects of the dispute during the dispute resolution process. The second reversal means that funds will be directly adjusted from these related accounts to correct the error or resolve the dispute, resulting in the second reversal outcome. This approach ensures the efficiency and accuracy of dispute resolution, avoiding unnecessary fund flows and accounting confusion.

[0059] The first processing result actually encompasses all reversal operations for credit transactions, namely the first reversal result (for returned transactions) and the second reversal result (for disputed adjustments). Both the first and second reversals update the balance information of the transaction-level account, as well as relevant data for any involved statistical or billing accounts, to reflect the latest transaction status.

[0060] The processing flow for credit transactions significantly enhances the efficiency, accuracy, and customer service quality of the credit card accounting management system. When a credit transaction occurs, it uses at least the transaction number and date for precise or fuzzy matching to locate the original transaction record. This intelligent matching mechanism ensures that credit transactions can be quickly and accurately matched with previous debit transactions, providing a solid foundation for subsequent processing. For return transactions, a first offset operation on the original transaction-level account immediately updates the account balance, eliminating redundant entries caused by the return. This immediate response not only simplifies the refund process but also maintains the real-time accuracy of customer accounts, improving customer experience. In the case of disputed settlements, a second offset operation is performed on the associated account, following the rules established during dispute registration. This operation can address customer objections in a targeted manner, restore the legitimate rights of the account, and avoid the resource waste and accounting chaos that might result from general offset operations. In summary, by subdividing credit transactions into two typical scenarios—return transactions and disputed settlements—and adopting corresponding first and second offset operations, a high degree of automation and refined management of credit transactions is achieved. This approach not only significantly shortens transaction processing time and reduces operational complexity, but also effectively ensures account accuracy and consistency by updating account balances and status in real time, thereby improving overall accounting quality and customer satisfaction. It also provides stronger data support for banks' risk control and compliance management.

[0061] Furthermore, after performing precise or fuzzy matching on the transaction requests based on the first information, the method further includes: when the transaction requests cannot be matched with the original transaction records, selecting a set of offsetting rules based on the account's overdue status; generating a dynamic priority based on the offsetting rule set, the number of overdue days, and the percentage of remaining principal; and performing a third offsetting based on the dynamic priority to obtain a third offsetting result.

[0062] When an attempt is made to precisely or fuzzily match a transaction request (credit transaction) based on the initial information, but no corresponding original transaction record is found, another processing logic is triggered to ensure that the effective processing of the transaction does not affect the correct status of the account. Specifically, when a transaction request cannot be matched with the original transaction record, this means that an attempt is made to find the relevant original transaction record using the transaction number, transaction date, and other possible initial information elements, but this has not been successfully located. This situation may occur in cases where the original transaction record is lost, data entry is incorrect, or the credit transaction is made a long time later, such as additional payments made voluntarily by the customer or disputed adjustments beyond the scope of the original transaction. Faced with a mismatch, the system will check the customer's account delinquency status to determine the subsequent reversal strategy. The account delinquency status reflects the customer's repayment performance over different time periods and may be categorized into several levels, such as normal, minor delinquency, and serious delinquency. One or more sets of reversal rules are pre-set, each corresponding to a different delinquency status, and include the principles and procedures for handling credit transactions when the original transaction cannot be directly matched. Choosing the right set of offsetting rules is a crucial step, as it directly affects how credit transaction amounts are applied fairly and effectively.

[0063] After determining the offsetting rule set, the number of overdue days and the proportion of remaining principal in the account are further considered. These two factors jointly influence the application order of the credit transaction amount. The longer the overdue days, the more likely the credit transaction should be used to offset the longest overdue debt. The proportion of remaining principal indicates the distribution of different types of balances in the account (such as interest, fees, and principal), determining which portion of the credit transaction amount should be offset first. By calculating dynamic priorities, the system can intelligently determine the order of offsetting interest first, then fees, and finally principal, or other orders defined by the offsetting rule set. A third offsetting operation is then performed according to the dynamic priorities, allocating the credit transaction amount to different balance types in the account according to priority. This process may involve multiple transaction-level accounts, ensuring that each credit transaction is appropriately applied to reduce the corresponding amount owed. The third offsetting result reflects the accurate adjustment of the customer's account through the dynamic priority mechanism when the original transaction record cannot be directly matched, maintaining the account's health while avoiding overpayment or incorrect reduction.

[0064] In complex situations where original transaction records cannot be directly matched, this process automates and intelligently processes credit transactions by selecting a set of reversal rules and generating dynamic priorities. It effectively balances customer interests, bank risk management, and compliance requirements, improving the flexibility and efficiency of accounting processing. By dynamically adjusting the reversal order, it ensures that funds are allocated reasonably, preventing potential account anomalies and customer dissatisfaction, while providing banks with more robust financial management and risk control tools. This approach is particularly important for customers with incomplete historical transaction records and complex account statuses.

[0065] In other embodiments of this application, the transaction request is determined to be a debit transaction, and a second processing is performed on the debit transaction to obtain a second processing result, including: when the transaction request is determined to be a debit transaction, checking the status of the overpayment account and generating overpayment write-off information based on the overpayment balance; based on the overpayment write-off information, performing dynamic pricing processing on the remaining transaction finance to obtain dynamically priced interest rate parameters; setting an account creation strategy based on the dynamically priced interest rate parameters and transaction type, registering the debit transaction to the corresponding transaction-level account according to the account creation strategy, and updating the account balance and interest rate to obtain updated transaction-level account information; wherein, the second processing result includes the overpayment write-off information, the dynamically priced interest rate parameters, and the updated transaction-level account information.

[0066] Specifically, upon confirming that the transaction request is a debit transaction, the system checks whether the customer has a balance in their overpayment account. An overpayment refers to the portion of a customer's repayment exceeding their current bill or overdraft limit. If an overpayment balance exists, overpayment reversal information is generated, including the overpayment account number, the reversal amount, and the remaining overpayment balance. This information is used to offset part of the debit transaction amount from the overpayment account, thereby reducing the customer's immediate liabilities. After the overpayment is reversed, dynamic pricing is applied to the remaining transaction amount of the debit transaction. Dynamic pricing is based on a series of parameters and rules, including the customer's risk level, historical transaction behavior, transaction amount, merchant type, and transaction time. This information is input into the pricing engine to generate dynamic interest rate parameters. For example, a higher interest rate is applied to large purchases by high-risk customers within a specific time period; conversely, a lower interest rate is applied to small purchases by low-risk customers. Dynamic pricing not only adjusts interest rates based on the specific circumstances of the customer and the transaction but also ensures a balance between bank revenue and risk control.

[0067] Furthermore, based on the aforementioned dynamically priced interest rate parameters and transaction types, an account creation strategy is set, including: determining the frequency risk information of the aforementioned debit transactions based on the aforementioned dynamically priced interest rate parameters and transaction types; when the aforementioned frequency risk information of the aforementioned debit transactions indicates high-frequency, low-risk transactions, a first account creation strategy is set, which is a strategy of merging transactions of the same type on the same day into the same account using a daily aggregation model; when the aforementioned frequency risk information of the aforementioned debit transactions indicates low-frequency, high-risk transactions, a second account creation strategy is set, which is a strategy of creating an independent account for each individual order; wherein, the aforementioned account creation strategy includes the aforementioned first account creation strategy and the aforementioned second account creation strategy, and the execution of the aforementioned account creation strategy is achieved through parameterized configuration.

[0068] Specifically, the analysis first determines the frequency and risk profile of current debit transactions by analyzing the interest rate parameters after dynamic pricing and the specific transaction type (such as consumption, cash withdrawal, installment payments, etc.). This analysis, based on big data and machine learning algorithms, comprehensively considers various factors such as the customer's historical behavior, credit score, and market conditions, aiming to accurately assess the potential risks of transactions and bank returns. For example, for small, frequent daily consumption, the risk is relatively low, and the interest rate parameter may be more moderate; conversely, for large, infrequent transactions, such as overseas shopping or consumption at high-risk merchants, the risk assessment is often higher, and the interest rate parameter may be adjusted accordingly.

[0069] For high-frequency, low-risk debit transactions, a primary account creation strategy is adopted: a daily aggregation model. This means that multiple low-risk transactions of the same type made by the same customer on the same day are not recorded in separate accounts, but are instead managed as a single transaction-level account. This strategy reduces the number of accounts, lowers storage and maintenance costs, while ensuring processing efficiency and resource utilization. Especially when handling a large number of small daily transactions, the daily aggregation model significantly reduces the system's burden, allowing resources to be focused on higher-risk or more complex transactions. In contrast, for low-frequency but high-risk debit transactions, a secondary account creation strategy is adopted: each individual order is recorded in a separate transaction-level account. Under this strategy, detailed information for each transaction, including amount, interest rate, transaction type, and merchant information, is recorded and managed independently, facilitating subsequent risk monitoring, dispute resolution, and accounting auditing. Independent account creation strategies are particularly suitable for handling large-value purchases, special transaction scenarios (such as pre-authorization and installment payments), or transactions with high-risk merchants. They ensure transparency and traceability for every transaction, helping banks to promptly identify potential risks and take countermeasures, while also meeting regulatory requirements for detailed record-keeping. Both the primary and secondary account creation strategies are implemented through parameterized configuration. This means that the rules and conditions for account creation can be flexibly adjusted according to different business needs and market environments, without the need for hard coding or redesigning the system architecture. Parameterized configuration provides high flexibility and customizability, enabling rapid adaptation to new business scenarios and risk management needs without undergoing cumbersome system modifications and testing processes.

[0070] This embodiment employs a first-account creation strategy with daily aggregation for high-frequency, low-risk debit transactions. This merges similar transactions from the same day into a single transaction-level account, significantly reducing the number of accounts, lowering system maintenance costs, and ensuring fast and smooth transaction processing. For low-frequency but high-risk debit transactions, a second-account creation strategy is used. This ensures that each transaction is recorded independently, providing detailed records and traceability for high-risk transactions, strengthening risk monitoring and compliance management, and providing necessary data support for potential dispute resolution. Flexible strategy adjustments through parameterized configuration not only optimize the structure and operational processes of the transaction-level account system but also significantly improve the efficiency, accuracy, and risk management capabilities of bank accounting processes.

[0071] The remaining debit transaction amount is credited to the transaction-level account selected according to the account creation strategy, and the account balance and interest rate information are updated based on the dynamically priced interest rate parameters. This operation ensures the accuracy of the account balance and the real-time nature of the interest rate, providing a foundation for subsequent billing and interest calculation. The updated transaction-level account information comprehensively reflects all details of this debit transaction processing, including transaction amount, balance type, interest rate parameters, account status, etc., which is crucial accounting data for the bank and also ensures the transparency and accuracy of customer bills.

[0072] The overpayment write-off information, dynamically priced interest rate parameters, and updated transaction-level account information generated from all the above processing steps together constitute the second processing result. This result comprehensively reflects the entire debit transaction processing process, including not only real-time financial changes but also risk- and scenario-based pricing decisions and account management adjustments.

[0073] The second processing mechanism for debit transactions enables refined management of debit transactions through intelligent write-off of overpayments, dynamic pricing, and policy-based account creation and updates. This process not only improves transaction processing efficiency but also ensures timely identification and control of risks by the bank. Furthermore, it provides personalized services and enhances customer satisfaction through real-time interest rate adjustments. In addition, the updating and management of account information strengthens accounting transparency and provides strong support for the bank's compliance management.

[0074] In some embodiments of this application, within a billing cycle, the first processing result and the second processing result are subjected to a third processing to generate billing-level data, including: within the billing cycle, obtaining outstanding transaction-level accounts based on the first processing result and the second processing result; obtaining the current effective interest rate, balance, and number of interest-bearing days, and calculating interest for each outstanding transaction-level account based on the current effective interest rate, the balance, and the number of interest-bearing days; after calculating the interest, creating interest-derived transaction-level accounts, and creating compound interest account types for the interest generated by the interest-derived transaction-level accounts, calculating the cost of funds generated by accumulated overdue interest, and obtaining interest processing results; based on the interest processing results, performing multi-dimensional aggregation calculations on all outstanding transaction-level accounts within the current cycle to obtain the billing-level data.

[0075] Specifically, at the start of the billing cycle, all outstanding transaction-level accounts from the previous cycle are identified. These accounts include balances that could not be matched and reversed in the third reversal results generated through credit transaction processing, as well as transaction information registered and dynamically priced after debit transaction processing. This process ensures that all pending borrowing and repayment information is taken into account in billing generation.

[0076] For each outstanding transaction-level account, its current effective interest rate, balance, and the number of interest-bearing days from the last billing date to the current billing date are extracted. Based on these key parameters, interest is calculated in segments based on the account balance, applying different interest rates according to the balance size and the interest-bearing period. This mechanism ensures the precision and reasonableness of interest calculation, avoiding excessively high interest on the entire bill due to a single large transaction, and increasing the transparency and fairness of interest calculation.

[0077] After interest calculation is completed, an interest-derived transaction-level account is created to record the interest generated by each transaction-level account. This is not simply a matter of summing up the interest; by creating new transaction-level accounts, each interest payment is independently recorded and tracked, facilitating subsequent dispute resolution and the implementation of interest rate benefits. For interest generated by interest-derived transaction-level accounts, a compound interest account type is also created to calculate the additional funding costs arising from the accumulation of overdue and unpaid interest. In this way, even in complex situations, such as consecutive overdue payments, the accrued compound interest can be accurately calculated, avoiding underestimation or overestimation of funding costs and ensuring the fairness of the rights and interests of both the bank and the customer.

[0078] The system performs multi-dimensional aggregated calculations on all outstanding transaction-level accounts within the current billing cycle, including principal categorization, interest fee differentiation, and compound interest calculation, generating bill-level data. This data includes key information such as the sum of each balance type, total interest for the cycle, minimum payment due, and total bill amount. Simultaneously, it dynamically calculates reductions for each component based on rule parameters, such as reductions in basic interest and compound interest increments, ensuring the final bill amount reflects all applicable discounts and fees. The generated bill-level data is synchronized to the outstanding balance field of the managed account, allowing customers to view their bill details in real-time via mobile applications or online banking, enhancing accounting transparency and customer satisfaction.

[0079] This embodiment achieves comprehensive management and accurate settlement of credit and debit transaction processing results within the billing cycle, significantly improving the efficiency and transparency of credit card billing. Specifically, it can automatically identify and integrate all outstanding transaction-level accounts, and accurately calculate the interest for each transaction by applying dynamic, currently effective interest rates. This avoids the injustice and inefficiency that may result from the uniform processing of different transaction backgrounds and risk levels in traditional methods. After interest calculation, interest-derived transaction-level accounts are created, and compound interest account types are further established to ensure that the cost of funds for overdue interest can be accurately tracked and calculated. This not only strengthens the bank's financial risk management but also provides customers with a clear view of interest composition, enhancing the service experience. Through multi-dimensional aggregation calculations, billing-level data containing information such as the balance, interest, and compound interest of all transaction-level accounts in the current period is generated. The comprehensiveness and accuracy of this data enable the bank to manage credit card business in a refined manner, while also allowing customers to understand their financial situation in real time and accurately, reducing billing disputes and improving overall operational efficiency and customer satisfaction.

[0080] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the credit card transaction data processing method of this application will be described in detail below with reference to specific embodiments.

[0081] This embodiment relates to a specific method for processing credit card transaction data, primarily applicable to banking systems. Transaction-level account lifecycle management is a core component of the credit card accounting system, spanning the entire process from transaction occurrence to bill generation. The following details its operational mechanism from four dimensions: new transaction request processing, credit transaction processing, debit transaction processing, and billing date processing. Credit transaction processing and debit transaction processing are parallel operations with no sequential relationship. Figure 3 As shown, the above method includes the following steps: Step 1: Receive transaction requests, route them to the transaction-level account type, and check parameters such as account limit and pricing. Step 2: Intelligent reversal processing of credit transactions. Step 3: Refined management of debit transactions. Step 4: Closed-loop processing of the billing cycle, including interest settlement, creation of interest account derivatives, and bill aggregation calculations.

[0082] Specifically, Figure 4 A flowchart for step 1 is shown, as follows: Figure 4As shown. Step 11: The system receives a new transaction request. Step 12: Message parsing extracts routing elements. When a transaction request is received, the system first extracts key elements through the message parsing engine. This includes obtaining management account information (including customer information, credit card product information, etc.), scenario information (merchant information, transaction region, transaction channel, etc.), and time information (transaction date, settlement date), etc., from the transaction request. Step 13: The engine routes and maps to the transaction-level account type. Based on the transaction information, the system executes the parameterized configuration matching rules to obtain the transaction type code, which is used for business scenario identification (such as online consumption, education installment payments, etc.). The transaction routing engine matches the transaction-level account type code based on the transaction type, combined with scenario variables (customer risk level, time period identifier), as the financial attribute definition of the balance component (such as 'principal of consumption for high-quality customers', 'interest on education installment payments', etc.), and associates it with differentiated pricing rules and scenario limit control units. Step 14: The system creates a transaction-level account and assigns a value. When creating a transaction-level account, you need to enter the basic information of the management account, balance type, pricing rules (interest rate, minimum repayment ratio), account aggregation method, creation time and parent account number, etc., for subsequent aggregation and calculation.

[0083] At this stage, a triple verification process will be performed: Step 15: Check the management account status. First, verify whether the management account status is normal, i.e., not in a cancelled or frozen state. Step 16: Second, verify the available credit limit through the credit limit control unit. Step 17: Finally, call the pricing center to obtain differentiated pricing parameters. The pricing engine generates interest rate fluctuation coefficients based on user profiles (customer risk level, historical repayment records) and scenario variables (transaction amount exceeding limit flag, merchant risk level). For example, high-quality customers can enjoy a discount on the benchmark interest rate when spending at specific merchants. These parameters will be persistently stored as the current effective interest rate and minimum repayment ratio attributes of the transaction-level account.

[0084] Regarding the intelligent offsetting of credit transactions in step 2, credit transactions mainly include scenarios such as repayment, return, and dispute adjustment. The processing logic follows a dynamic priority decision model. Step 21: Original transaction tracing mechanism: precise / fuzzy matching is implemented through serial number or card number + transaction date + other elements. Step 22 (1): For return transactions, the original account is offset first, and for dispute adjustment, the related account is offset in a targeted manner. This process requires updating the balance information of the original transaction-level account and adjusting the credit amount of the statistical account in conjunction. Step 22 (2): Tiered offsetting strategy: when the original transaction cannot be matched, a multi-dimensional decision matrix is ​​activated. First, the offsetting rule set is selected according to the account overdue status, and then a dynamic priority is generated by comprehensively considering parameters such as overdue days and the proportion of remaining principal. When executing, the priority is given to interest > fees > principal. Step 23: Intelligent collection of overpayments: after the offsetting is completed, the remaining amount is transferred to the overpayment account. The management account is updated in real time and synchronized with the big data risk control platform to provide data support for subsequent credit decisions.

[0085] Regarding the refined management of debit transactions in step 3, an asset-side record is generated when a debit transaction is recorded. Its processing flow reflects refined control: Step 31: Overpayment Priority Write-off Mechanism: The status of the overpayment account is automatically checked before deduction. For consumer transactions, the overpayment account balance is checked and reversed. The reversal process generates a repayment allocation history and records information such as the original transaction account number, the reversal amount, and the remaining overpayment. Step 32: Dynamic Pricing Creation Rules: After the overpayment reversal is completed, the remaining transaction amount triggers real-time pricing decisions. User profiles, transaction characteristics, and risk signals are input into the pricing engine, outputting scenario-based interest rate parameters. For example, for high-risk customers consuming jewelry at overseas merchants, the interest rate may be increased by several basis points from the benchmark rate, forming the current effective interest rate and locking it to their transaction-level account. Step 33: Intelligent Tiered Account Creation: Differentiated account creation strategies are implemented based on transaction type characteristics. High-frequency, low-risk transactions use a daily aggregation model, merging similar transactions into the same account; low-frequency, high-risk transactions use single-transaction creation, such as creating separate accounts for each installment order and associating them with the installment number. This strategy is implemented through parameterized configuration.

[0086] Step 4 involves the closed-loop processing of the billing cycle. The billing date is a key node in the account cycle and is used to complete the final calculation of the cost of funds. Figure 5 The flowchart for step 4 is shown. Step 41: Precise Interest Settlement: Scan all outstanding transaction-level accounts and apply segmented interest calculation to non-interest-free assets (such as cash withdrawal principal and overdue payments). Step 42: Use an event-driven interest calculation engine to obtain the current effective interest rate, balance, and number of interest-bearing days. Step 43: Calculate interest independently for each transaction-level account, i.e., calculate "Interest = Balance × Independent Interest Rate × Number of Interest-bearing Days" independently for each transaction-level account, and reduce interest according to rule parameters. Step 44: Create Interest-Derived Transaction-Level Accounts After Interest Calculation: For principal accounts, automatically create transaction-level accounts for consumption interest or cash withdrawal interest. These accounts inherit attributes such as the installment order number of the original transaction and establish a traceability relationship with the principal account through the parent transaction-level account number field. Step 45: Establish a traceability relationship with the principal account through the parent transaction-level account. For interest generated by the interest account, create a separate compound interest account type to calculate the cost of funds generated by accumulated overdue interest. Step 46: Bill Amount Aggregation Calculation: The bill generation module filters transaction-level accounts for the current period based on the bill status code, and performs multi-dimensional aggregation for accounts of the same currency. Principal is categorized and summarized by transaction type, while interest is differentiated between basic interest and compound interest. Simultaneously, the minimum repayment amount is dynamically calculated: consumption principal is converted using the currently effective minimum repayment ratio, cash withdrawal interest is fully included, and late payment penalties are handled according to tiered reduction rules. The final generated bill-level data will be synchronized to the remaining outstanding amount field of the management account, supporting real-time querying on mobile devices.

[0087] The entire lifecycle is tracked through the transaction account table.

[0088] Transaction-level accounts support flexible configuration and routing of transaction types. Accounts can be freely opened based on transaction-based business types or scenarios, flexibly supporting various retail business models. They possess the capability to support scenario-based open accounts, reducing operating costs and enabling rapid response to changes in business scenarios. The transaction-level account system ensures one transaction-level account per transaction, achieving four levels of segmentation through transaction-level account type coding fields. Balance and pricing models can be freely configured according to rules or big data decisions, providing an on-demand, dynamic, and real-time account processing solution. This allows for refined balance and pricing operations, further increasing revenue growth points and reducing operational risks. The transaction-level account system uses transaction-level accounts as the basic unit, supplemented by management accounts, statistical accounts, and billing accounts. It allows for statistical aggregation based on different balance types, balancing business revenue and system efficiency, and supports on-demand selection of transaction account granularity. It is compatible with traditional credit card balance architectures while also addressing future transaction-level differentiation, enabling further analysis of overall business operations and user profile analysis.

[0089] This application also provides a credit card transaction data processing apparatus. It should be noted that the credit card transaction data processing apparatus of this application can be used to execute the credit card transaction data processing method 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.

[0090] The following describes the credit card transaction data processing apparatus provided in the embodiments of this application.

[0091] Figure 6 This is a structural block diagram of a credit card transaction data processing apparatus according to an embodiment of this application. Figure 6As shown, the device includes a first determining unit 61, a second determining unit 62, a first processing unit 63, a second processing unit 64, and a third processing unit 65. The first determining unit receives a transaction request and determines a transaction-level account type code based on the element information of the transaction request. The second determining unit determines whether the transaction request is a credit transaction based on the transaction-level account type code. The first processing unit performs first processing on the credit transaction if it is a credit transaction, obtaining a first processing result. The second processing unit determines the transaction request is a debit transaction if it is not a credit transaction, and performs second processing on the debit transaction, obtaining a second processing result. The third processing unit performs third processing on the first and second processing results within a billing cycle to generate billing-level data. This billing-level data is used for real-time querying and reflecting the principal, interest, and fees of each transaction. The third processing includes interest settlement, interest account creation, and bill aggregation calculation.

[0092] This embodiment dynamically determines the transaction-level account type code and intelligently judges the nature of the transaction, achieving efficient and accurate processing of credit and debit transactions and reducing erroneous operations. Especially within the billing cycle, by integrating the first and second processing results, interest is calculated, interest accounts are created, and finally, detailed billing-level data is aggregated and calculated. This data not only reflects the principal, interest, and fee information of each transaction in real time, but also supports users' instant queries, greatly improving the transparency of bank accounting and customer satisfaction. In particular, through refined management and a closed-loop data chain, the bank's operational efficiency and risk management capabilities are optimized, thereby solving the limitations of existing credit card transaction processing technologies, including low risk management capabilities and low data utilization.

[0093] In the specific implementation process, the first determining unit includes an extraction module, an execution module, and a determining module. The extraction module is used to receive the transaction request and use a message parsing engine to extract the element information of the transaction request, including management account information, scenario information, and time information; the execution module is used to execute the parameterized matching rules according to the element information to obtain the transaction type of the transaction request; the determining module is used to determine the transaction-level account type code based on the transaction type.

[0094] By employing a message parsing engine to accurately extract management account information, scenario information, and time information from transaction requests, and combining this with parameterized matching rules to determine the transaction type, and finally establishing a transaction-level account type code based on the transaction type, this series of processes significantly improves the efficiency and accuracy of credit card transaction data processing. First, it enables rapid and accurate identification and classification of transactions, laying the foundation for subsequent refined management and personalized services. Second, the determination of the transaction-level W account type code enables dynamic and scenario-based management of transactions, supporting real-time differentiated pricing and risk assessment, enhancing the flexibility and responsiveness of financial services. Finally, it ensures the integrity and traceability of transaction data, providing detailed and accurate information support for bill generation, dispute resolution, and compliance audits, improving the transparency of the overall accounting system and customer satisfaction. This embodiment ensures the correct classification of transactions and the accurate establishment of transaction-level accounts, laying a solid data foundation for subsequent credit and debit transaction processing and bill generation.

[0095] Furthermore, the aforementioned apparatus also includes a creation unit, used to create a transaction-level account according to the transaction-level account type code after determining the transaction-level account type code based on the transaction type. The transaction-level account is used to store attribute information, including basic management account information, balance type, pricing rules, account aggregation method, creation time, and parent account number.

[0096] After determining the transaction-level account type code, a corresponding transaction-level account is created based on this code, storing comprehensive attribute information including basic account information, balance type, pricing rules, account aggregation method, creation time, and parent account number. This significantly enhances the accuracy and flexibility of credit card transaction data processing. On the one hand, by storing rich attribute information, deep classification and management of transaction data are achieved, ensuring that each transaction can be accurately identified and tracked, guaranteeing data integrity and traceability in terms of principal, interest, and fees. On the other hand, the parameterized configuration of pricing rules and account aggregation methods allows banks to optimize account aggregation strategies while implementing real-time differentiated pricing based on factors such as merchant, time period, and risk score. This balances business needs with the rational use of system resources, improving the overall efficiency of accounting processing. Furthermore, recording the creation time and parent account number of the transaction-level account provides strong support for subsequent bill generation and data analysis, ensuring the transparency and consistency of financial information, thereby improving customer service quality and risk control capabilities. In summary, this embodiment effectively promotes the scenario-based response speed, refined operational capabilities, and data integration level of credit card business.

[0097] In some embodiments of this application, the first processing unit includes a matching module, a first reversal module, and a second reversal module. The matching module is used to perform precise or fuzzy matching on the credit transaction based on first information when the transaction request is the credit transaction, to obtain the original transaction record. The first information includes at least a serial number and a transaction date. The first reversal module is used to perform a first reversal on the original transaction-level account when the original transaction record indicates that the credit transaction is a return transaction, to obtain a first reversal result. The second reversal module is used to perform a second reversal according to the associated account at the time of dispute registration when the original transaction record indicates that the credit transaction is a disputed reconciliation, to obtain a second reversal result. The first processing result includes both the first reversal result and the second reversal result.

[0098] The processing flow for credit transactions significantly enhances the efficiency, accuracy, and customer service quality of the credit card accounting management system. When a credit transaction occurs, it uses at least the transaction number and date for precise or fuzzy matching to locate the original transaction record. This intelligent matching mechanism ensures that credit transactions can be quickly and accurately matched with previous debit transactions, providing a solid foundation for subsequent processing. For return transactions, a first offset operation on the original transaction-level account immediately updates the account balance, eliminating redundant entries caused by the return. This immediate response not only simplifies the refund process but also maintains the real-time accuracy of customer accounts, improving customer experience. In the case of disputed settlements, a second offset operation is performed on the associated account, following the rules established during dispute registration. This operation can address customer objections in a targeted manner, restore the legitimate rights of the account, and avoid the resource waste and accounting chaos that might result from general offset operations. In summary, by subdividing credit transactions into two typical scenarios—return transactions and disputed settlements—and adopting corresponding first and second offset operations, a high degree of automation and refined management of credit transactions is achieved. This approach not only significantly shortens transaction processing time and reduces operational complexity, but also effectively ensures account accuracy and consistency by updating account balances and status in real time, thereby improving overall accounting quality and customer satisfaction. It also provides stronger data support for banks' risk control and compliance management.

[0099] Furthermore, the aforementioned apparatus also includes a selection unit, a generation unit, and a reduction unit. The selection unit is used to select a reduction rule set based on the account's overdue status after performing precise or fuzzy matching on the transaction request based on the first information, in the case where the transaction request cannot be matched with the original transaction record; the generation unit is used to generate a dynamic priority based on the reduction rule set, the number of overdue days, and the proportion of remaining principal; the reduction unit is used to perform a third reduction based on the dynamic priority to obtain a third reduction result.

[0100] In complex situations where original transaction records cannot be directly matched, this process automates and intelligently processes credit transactions by selecting a set of reversal rules and generating dynamic priorities. It effectively balances customer interests, bank risk management, and compliance requirements, improving the flexibility and efficiency of accounting processing. By dynamically adjusting the reversal order, it ensures that funds are allocated reasonably, preventing potential account anomalies and customer dissatisfaction, while providing banks with more robust financial management and risk control tools. This approach is particularly important for customers with incomplete historical transaction records and complex account statuses.

[0101] In some other embodiments of this application, the second processing unit includes a checking module, a pricing processing module, and an updating module. The checking module checks the status of the overpayment account and generates overpayment write-off information based on the overpayment balance when the transaction request is determined to be a debit transaction. The pricing processing module performs dynamic pricing processing on the remaining transaction funds based on the overpayment write-off information to obtain dynamically priced interest rate parameters. The updating module sets an account creation strategy based on the dynamically priced interest rate parameters and the transaction type, registers the debit transaction to the corresponding transaction-level account according to the account creation strategy, and updates the account balance and interest rate to obtain updated transaction-level account information. The second processing result includes the overpayment write-off information, the dynamically priced interest rate parameters, and the updated transaction-level account information.

[0102] Furthermore, the aforementioned update module includes a determination submodule, a first setting submodule, and a second setting submodule. The determination submodule is used to determine the frequency risk information of the aforementioned debit transaction based on the interest rate parameters after dynamic pricing and the aforementioned transaction type. The first setting submodule is used to set a first account creation strategy when the frequency risk information of the aforementioned debit transaction is high-frequency, low-risk. The first account creation strategy is a strategy of merging transactions of the same type on the same day into the same account using a daily aggregation mode. The second setting submodule is used to set a second account creation strategy when the frequency risk information of the aforementioned debit transaction is low-frequency, high-risk. The second account creation strategy is a strategy of creating an independent account for each individual order. The aforementioned account creation strategy includes the aforementioned first account creation strategy and the aforementioned second account creation strategy, and the execution of the aforementioned account creation strategy is achieved through parameterized configuration.

[0103] This embodiment employs a first-account creation strategy with daily aggregation for high-frequency, low-risk debit transactions. This merges similar transactions from the same day into a single transaction-level account, significantly reducing the number of accounts, lowering system maintenance costs, and ensuring fast and smooth transaction processing. For low-frequency but high-risk debit transactions, a second-account creation strategy is used. This ensures that each transaction is recorded independently, providing detailed records and traceability for high-risk transactions, strengthening risk monitoring and compliance management, and providing necessary data support for potential dispute resolution. Flexible strategy adjustments through parameterized configuration not only optimize the structure and operational processes of the transaction-level account system but also significantly improve the efficiency, accuracy, and risk management capabilities of bank accounting processes.

[0104] The second processing mechanism for debit transactions enables refined management of debit transactions through intelligent write-off of overpayments, dynamic pricing, and policy-based account creation and updates. This process not only improves transaction processing efficiency but also ensures timely identification and control of risks by the bank. Furthermore, it provides personalized services and enhances customer satisfaction through real-time interest rate adjustments. In addition, the updating and management of account information strengthens accounting transparency and provides strong support for the bank's compliance management.

[0105] In some embodiments of this application, the third processing unit includes an acquisition module, a first calculation module, a second calculation module, and a third calculation module. The acquisition module is used to acquire outstanding transaction-level accounts within the billing cycle based on the first and second processing results. The first calculation module is used to acquire the current effective interest rate, balance, and number of interest-bearing days, and calculate interest for each outstanding transaction-level account based on these factors. The second calculation module is used to create interest-derived transaction-level accounts after the interest calculation, create compound interest account types for the interest generated by these interest-derived transaction-level accounts, calculate the cost of funds generated by accumulated overdue interest, and obtain the interest processing result. The third calculation module is used to perform multi-dimensional aggregation calculations on all outstanding transaction-level accounts within the current cycle based on the interest processing result, and obtain the billing-level data.

[0106] This embodiment achieves comprehensive management and accurate settlement of credit and debit transaction processing results within the billing cycle, significantly improving the efficiency and transparency of credit card billing. Specifically, it can automatically identify and integrate all outstanding transaction-level accounts, and accurately calculate the interest for each transaction by applying dynamic, currently effective interest rates. This avoids the injustice and inefficiency that may result from the uniform processing of different transaction backgrounds and risk levels in traditional methods. After interest calculation, interest-derived transaction-level accounts are created, and compound interest account types are further established to ensure that the cost of funds for overdue interest can be accurately tracked and calculated. This not only strengthens the bank's financial risk management but also provides customers with a clear view of interest composition, enhancing the service experience. Through multi-dimensional aggregation calculations, billing-level data containing information such as the balance, interest, and compound interest of all transaction-level accounts in the current period is generated. The comprehensiveness and accuracy of this data enable the bank to manage credit card business in a refined manner, while also allowing customers to understand their financial situation in real time and accurately, reducing billing disputes and improving overall operational efficiency and customer satisfaction.

[0107] The aforementioned credit card transaction data processing device includes a processor and a memory. The first determining unit, second determining unit, first processing unit, second processing unit, and third processing 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 are located in the same processor; alternatively, the modules may be located in different processors in any combination.

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

[0109] This invention provides a computer-readable storage medium including a stored program, wherein the program, when running, controls the device containing the computer-readable storage medium to execute the credit card transaction data processing method.

[0110] This invention provides a processor for running a program, wherein the program executes the credit card transaction data processing method.

[0111] 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 implements the steps of the aforementioned credit card transaction data processing method. The device described herein can be a server, PC, PAD, mobile phone, etc.

[0112] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform the steps of initializing the above-described credit card transaction data processing method.

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

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

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

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

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

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

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

[0120] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, 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.

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

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

[0123] 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 method for processing credit card transaction data, characterized in that, include: Receive a transaction request and determine the transaction-level account type code based on the element information of the transaction request; Determine whether the transaction request is a credit transaction based on the transaction-level account type code; If the transaction request is a credit transaction, the credit transaction is processed first to obtain a first processing result; If the transaction request is not a credit transaction, the transaction request is determined to be a debit transaction, and the debit transaction is subjected to a second processing to obtain a second processing result; During the billing cycle, the first processing result and the second processing result are subjected to a third processing to generate billing-level data. The billing-level data is used to query and reflect the principal, interest and fees of each transaction in real time. The third processing includes interest settlement, interest account creation and bill aggregation calculation.

2. The method according to claim 1, characterized in that, Receiving a transaction request and determining a transaction-level account type code based on the element information of the transaction request, including: The transaction request is received, and the message parsing engine is used to extract the element information of the transaction request, including management account information, scenario information, and time information; The parameterized matching rules are executed based on the element information to obtain the transaction type of the transaction request; The transaction-level account type code is determined based on the transaction type.

3. The method according to claim 2, characterized in that, After determining the transaction-level account type code based on the transaction type, the method further includes: A transaction-level account is created based on the transaction-level account type code. The transaction-level account is used to store attribute information, including basic management account information, balance type, pricing rules, account aggregation method, creation time, and parent account number.

4. The method according to claim 1, characterized in that, When the transaction request is the credit transaction, the credit transaction undergoes a first processing step to obtain a first processing result, including: In the case that the transaction request is the credit transaction, the credit transaction is precisely or fuzzily matched based on the first information to obtain the original transaction record, wherein the first information includes at least the serial number and the transaction date; If the original transaction record indicates that the credit transaction is a return transaction, a first reversal is performed on the original transaction-level account to obtain the first reversal result; If the original transaction record indicates that the credit transaction is a disputed reconciliation, a second reversal is performed according to the related account at the time of dispute registration to obtain the second reversal result; The first processing result includes the first reduction result and the second reduction result.

5. The method according to claim 4, characterized in that, After performing precise or fuzzy matching on the transaction request based on the first information, the method further includes: If the transaction request cannot be matched with the original transaction record, select the set of offset rules based on the account's overdue status; Dynamic priority is generated based on the aforementioned set of offsetting rules, the number of overdue days, and the percentage of remaining principal. The third reduction is performed based on the dynamic priority to obtain the third reduction result.

6. The method according to claim 1, characterized in that, The transaction request is determined to be a debit transaction, and the debit transaction undergoes a second processing step to obtain a second processing result, including: If the transaction request is determined to be a debit transaction, check the status of the overpayment account and generate overpayment write-off information based on the overpayment balance; Based on the overpayment write-off information, the remaining transaction amount is dynamically priced to obtain the interest rate parameters after dynamic pricing. Based on the interest rate parameters and transaction type after dynamic pricing, an account creation strategy is set, and the debit transaction is registered to the corresponding transaction-level account according to the account creation strategy. The account balance and interest rate are then updated to obtain the updated transaction-level account information. The second processing result includes the overpayment write-off information, the interest rate parameters after dynamic pricing, and the updated transaction-level account information.

7. The method according to claim 6, characterized in that, Based on the dynamically priced interest rate parameters and transaction type, an account creation strategy is set, including: The frequency risk information of the debit transaction is determined based on the interest rate parameters after dynamic pricing and the transaction type. When the frequency risk information of the debit transaction is a high-frequency, low-risk transaction, a first account creation strategy is set. The first account creation strategy is to use a daily summary mode to merge the same type of transactions into the same account. When the frequency risk information of the debit transaction is low-frequency high-risk transaction, a second account creation strategy is set, which is a strategy of creating an account independently for each single order; The account creation strategy includes a first account creation strategy and a second account creation strategy, and the execution of the account creation strategy is implemented using parameterized configuration.

8. The method according to claim 1, characterized in that, Within the billing cycle, the first processing result and the second processing result are subjected to a third processing to obtain the generated billing hierarchy data, including: Within the billing cycle, outstanding transaction-level accounts are obtained based on the first processing result and the second processing result; Obtain the current effective interest rate, balance, and number of interest-bearing days, and calculate interest for each of the outstanding transaction-level accounts based on the current effective interest rate, the balance, and the number of interest-bearing days; After performing the interest calculation, an interest derivative transaction level account is created, and a compound interest account type is created for the interest generated by the interest derivative transaction level account. The cost of funds generated by the accumulated overdue interest is calculated to obtain the interest processing result. Based on the interest processing results, multi-dimensional aggregation calculations are performed on all outstanding transaction-level accounts within this period to obtain the billing-level data.

9. A credit card transaction data processing device, characterized in that, include: The first determining unit is used to receive a transaction request and determine a transaction-level account type code based on the element information of the transaction request. The second determining unit is used to determine whether the transaction request is a credit transaction based on the transaction-level account type code; The first processing unit is configured to perform a first processing on the credit transaction when the transaction request is the credit transaction, and obtain a first processing result; The second processing unit is configured to determine that the transaction request is a debit transaction if the transaction request is not a credit transaction, and to perform a second processing on the debit transaction to obtain a second processing result. The third processing unit is used to perform a third processing on the first processing result and the second processing result within the billing cycle to generate billing-level data. The billing-level data is used to query and reflect the principal, interest and fees of each transaction in real time. The third processing includes interest settlement, interest account creation and bill aggregation calculation.

10. 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 containing the computer-readable storage medium to perform the credit card transaction data processing method according to any one of claims 1 to 8.

Images