Transaction data real-time verification method and system based on multiple payment channels

Abstract

The invention discloses a transaction data real-time verification method based on multiple payment channels, and relates to the field of data verification, and the method comprises the steps: calling a corresponding payment plug-in, and generating a payment two-dimensional code; after aggregation payment is completed, a payment order is generated, and the payment order is stored in a payment database; all payment orders in the to-be-reconciliated time period in the payment database are called, order reconciliation is completed by querying all reconciliated orders and combining all the payment orders and the reconciliated orders, and a plurality of abnormal users are output according to an order reconciliation result; and querying the medical resource consumption of all abnormal users, and outputting an exception handling strategy in combination with the medical resource consumption and a pre-acquired fund risk control rule. The account checking efficiency and the account checking accuracy can be effectively improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of data verification, and in particular to a method and system for real-time verification of transaction data based on multiple payment channels. Background Art

[0002] With the widespread application of information technology in the healthcare field, more and more hospitals are introducing diverse payment methods to enhance the patient experience and improve operational efficiency. However, this diversity of payment methods also increases the workload and complexity of reconciliation, potentially leading to errors and failure to promptly detect abnormal payment situations such as unilateral payments and duplicate payments, thus impacting the patient experience and hospital operational efficiency.

[0003] The existing reconciliation method primarily relies on the hospital's finance department using automated or semi-automated tools to reconcile accounts with each payment platform individually. However, this approach significantly increases the workload and reduces efficiency, especially for large hospitals, severely impacting normal operations. Furthermore, orders paid through multiple channels are prone to misjudgment, impacting the patient experience. Summary of the Invention

[0004] The embodiments of the present application provide a method and system for real-time verification of transaction data based on multiple payment channels, which is used to solve the problem that the existing technology is difficult to achieve high-efficiency and accurate reconciliation.

[0005] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions: In a first aspect, a method for real-time transaction data verification based on multiple payment channels is provided, which is applied to an online hospital system. The online hospital system includes an aggregated payment platform and a hospital information center. The aggregated payment platform and the hospital information center are in communication with each other. The hospital information center includes a payment database and an account arrival database. The method includes: After receiving the payment request from the target user through the aggregated payment platform, the corresponding payment plug-in is called based on the payment request, and the payment QR code is generated by the payment plug-in; When the target user completes the aggregate payment through the payment QR code, a payment order is generated and stored in the payment database; When the preset reconciliation time node is reached, all payment orders within the reconciliation period are retrieved from the payment database, and all received orders within the reconciliation period are queried through the received database. The order reconciliation is completed by combining all payment orders and received orders, and a number of abnormal users are output based on the order reconciliation results.

[0006] Optionally, after receiving the payment request from the target user through the aggregated payment platform, calling the corresponding payment plug-in based on the payment request, and generating a payment QR code through the payment plug-in includes the following steps: After receiving the payment request from the target user through the aggregated payment platform, the order API service of the aggregated payment platform is called to create a transaction order based on the payment request; Retrieve the target user's identity, and verify the target user's transaction permissions based on the identity and the preset permission rule table; If the target user's permission verification passes, the target user's merchant number is calculated according to the fund allocation algorithm; According to the merchant number, the corresponding configuration information is obtained through the aggregated payment platform, and the transaction order is encrypted using the key in the configuration information to obtain the encrypted order; Call the corresponding payment plug-in according to the merchant number, send the encrypted order to the payment server of the aggregated payment platform through the payment plug-in, and use the payment server to verify the encrypted order; If the encrypted order verification passes, the payment server will generate a payment QR code based on the encrypted order.

[0007] Optionally, retrieving all payment orders in the waiting reconciliation period from the payment database, querying all received orders in the waiting reconciliation period from the received accounts database, combining all payment orders and received orders to complete order reconciliation, and outputting several abnormal users based on the order reconciliation results includes the following steps: Retrieve all payment orders in the payment database within the waiting period for reconciliation, and query all received orders in the waiting period for reconciliation through the hospital information center; Based on the regular matching algorithm, key payment data and key account data are extracted from all payment orders and account arrival orders respectively; Complete the synchronous sampling of all key payment data and key account data through the preset time window, and extract several abnormal sub-time periods within the time period to be reconciled based on the synchronous sampling results; Complete data matching of key payment data and key account data for all abnormal sub-time periods to obtain multiple transaction data sets; For any abnormal sub-time period, the rule engine is used to check for explicit abnormal orders within the abnormal sub-time period. Use the hidden anomaly recognition model to complete the hidden state inference of the entire transaction data set, and determine the hidden abnormal orders in the time period to be reconciled based on the hidden state inference results; Combine all explicit abnormal orders and implicit abnormal orders to determine all abnormal orders in the time period to be reconciled, and output the corresponding abnormal users based on the abnormal orders.

[0008] Optionally, completing synchronous sampling of all key payment data and key account arrival data through a preset time window, and extracting several abnormal sub-time periods within the time period to be reconciled based on the synchronous sampling results includes the following steps: Retrieve historical reconciliation records from the hospital information center, calculate the time difference between the aggregated payment platform's arrival, and determine the time compensation parameters between key payment data and key arrival data based on the time difference; Sort the key payment data and key account arrival data by timestamp to obtain the time-series payment sequence and time-series account arrival sequence; Complete the timestamp offset alignment of all time-series payment sequences and time-series account arrival sequences according to the time compensation parameters; The transaction indicators of the offset-aligned time series payment sequence and time series account arrival sequence are synchronously collected through the preset time window, and several abnormal sub-time periods are screened out from the time period to be reconciled based on the transaction indicators.

[0009] Optionally, synchronously collecting transaction indicators of the offset-aligned time-series payment sequence and time-series account arrival sequence through a preset time window, and filtering out several abnormal sub-time periods from the time period to be reconciled based on the transaction indicators, includes the following steps: Synchronously collect transaction indicators for time-series payment sequences and time-series account arrival sequences with aligned timestamps through pre-set time windows. Transaction indicators include the total transaction amount and total transaction frequency of key payment data and key account arrival data within each time window. For any time window, calculate the comprehensive deviation index of the time-series payment sequence and time-series account arrival sequence within the time window based on the transaction indicators; If the comprehensive deviation index is within the preset index threshold range, the time window is marked as an abnormal time window; Merge the abnormal time windows based on their timestamps to obtain several consecutive abnormal windows, and determine several abnormal sub-time periods within the reconciliation period based on the consecutive abnormal windows. Optionally, verifying the explicit abnormal orders within the abnormal sub-time period based on the rule engine includes the following steps: Convert pre-acquired medical payment rules into structured rules and build a rule engine based on the structured rules; Use the template matching algorithm to extract the core order fields of all payment orders and receipt orders within the abnormal sub-time period, and then integrate all core order fields with the corresponding transaction data sets into multiple core transaction information; Input all core order information into the rule engine in sequence, verify the core transaction information through the rule engine, and output the engine verification results; Determine the explicit abnormal orders within the abnormal sub-time period based on the engine verification results.

[0010] Optionally, using a latent anomaly recognition model to complete latent state inference of the entire transaction data set and determining latent abnormal orders in the time period to be reconciled based on the latent state inference results includes the following steps: Filter out normal transaction data from historical reconciliation records, which are stored in the hospital information center; Normal transaction data is used as a training set, and unsupervised learning is used to train the latent anomaly recognition model until the latent anomaly recognition model outputs the maximum likelihood probability. The latent anomaly recognition model is built based on the hidden Markov model; Construct the transaction observation sequence of the entire transaction data set; All transaction observation sequences are sequentially input into the trained implicit anomaly recognition model, and the joint probability of each transaction observation sequence in the implicit anomaly recognition model is calculated through the forward algorithm; The transaction observation sequences whose joint probability is less than the preset probability threshold are marked as abnormal observation sequences, and the implicit abnormal orders of all abnormal sub-time periods are determined based on the abnormal observation sequences.

[0011] Optionally, the method further includes the following steps: For any abnormal user, the hospital information center will query the abnormal user's medical resource consumption and calculate the abnormal user's medical payment amount based on the medical resource consumption; Calculate the medical payment amount of the abnormal user based on the incoming orders and payment orders corresponding to the abnormal user; If the amount of medical expenses to be paid is greater than the amount of medical expenses already paid, a payment reminder message will be sent to the abnormal user; If the amount of medical expenses to be paid is less than the amount of medical expenses already paid, a medical refund strategy will be generated based on the pre-acquired fund risk control rules.

[0012] In a second aspect, the present application provides a machine-readable storage medium having instructions stored thereon, the instructions being used to enable a machine to execute a method for real-time verification of transaction data based on multiple payment channels according to any one of the first aspects.

[0013] In a third aspect, the present application provides a real-time transaction data verification system based on multiple payment channels, comprising: a memory configured to store instructions; and A processor is configured to call instructions from a memory and, when executing the instructions, is capable of implementing the method for real-time verification of transaction data based on multiple payment channels according to any one of the first aspects.

[0014] Through the above technical solution, payment orders from different channels are uniformly stored in the payment database through the aggregated payment platform, so that in the subsequent reconciliation process, there is no need to reconcile with each payment platform separately, which greatly reduces the reconciliation workload and improves the reconciliation efficiency. Then, the transaction indicators of payment orders and incoming orders in the time period to be reconciled are synchronously collected through the time window, and the payment orders and incoming orders are batch verified based on the transaction indicators. Several abnormal sub-time periods are quickly screened out, further reducing the subsequent reconciliation workload. Then, the rule engine and hidden Markov model (HMM) are used to accurately verify the orders in all abnormal sub-time periods, identify abnormal orders, and formulate subsequent abnormality handling strategies based on the medical resource consumption of the abnormal users corresponding to the abnormal orders, thereby avoiding financial losses to the hospital and patients. In summary, this application effectively reduces the hospital's reconciliation workload and reconciliation accuracy, while improving the hospital's financial management efficiency and patient satisfaction.

[0015] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A flowchart of a method for real-time verification of transaction data based on multiple payment channels provided in an embodiment of the present application; Figure 2 A schematic diagram of the structure of an online hospital system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0017] To make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the specific implementation methods described herein are only used to illustrate and explain the embodiments of the present application and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0018] It should be noted that if the embodiments of the present application involve directional indications (such as up, down, left, right, front, back, etc.), such directional indications are only used to explain the relative position relationship, movement status, etc. between the various components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0019] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present application, the descriptions of "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of such features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the fact that they can be implemented by ordinary technicians in this field. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0020] Figure 1 The following schematically shows a flow chart of a method for real-time verification of transaction data based on multiple payment channels according to an embodiment of the present application. Figure 1 As shown, an embodiment of the present application provides a method for real-time verification of transaction data based on multiple payment channels, which is applied to an online hospital system. The online hospital system includes an aggregated payment platform and a hospital information center. The aggregated payment platform and the hospital information center are communicatively connected. The hospital information center includes a payment database and an account arrival database. The method may include the following steps: S101. After receiving the payment request of the target user through the aggregated payment platform, the corresponding payment plug-in is called based on the payment request, and a payment QR code is generated through the payment plug-in.

[0021] In this embodiment, referring to Figure 2 The aggregation payment platform includes a payment module and a refund module, and is connected to the hospital information center. The aggregation payment platform provides a unified payment interface and background management system by establishing a unified payment aggregation service and interface standard. During the payment process, there is no need to switch between multiple payment applications. The payment can be completed through an aggregation payment platform. The aggregation payment platform also includes a payment plug-in management module and an order service module. The payment plug-in management module can plug-in the connection of different payment channels such as bank cards and medical insurance to realize aggregated payment. The order service module is used to manage the security control of core transaction processes such as order creation, payment application, payment confirmation, business application, business confirmation, etc., to realize pre-payment application, verify whether the payment information is correct, and confirm after payment to achieve complete record of transaction elements.

[0022] When a target user clicks "pay" on the front-end (such as the payment interface of an online hospital mini-program), the aggregated payment platform immediately receives the target user's payment request and calls the order API service to create a transaction order. The transaction order includes a unique order number generated by the order API service for the transaction, which serves as a unique identifier for the subsequent payment process, as well as basic order information, including the payment amount, patient name, and registered department. Next, the target user's identity, such as user ID, mobile phone number, and membership card number, is extracted from the payment request or user session. If the target user is not logged in, an identity authentication process may be triggered. Based on the target user's identity, the platform verifies whether the target user has permission to perform the transaction by querying a pre-defined permission rule table, such as merchant level, user type, and transaction limit. If the target user's permission is verified, a pre-defined fund allocation algorithm is used to match the target user with a corresponding merchant number based on the patient's identity, department, and service type (e.g., outpatient, inpatient, or pharmaceutical). Based on the merchant number, the platform then retrieves the corresponding configuration information from the aggregated payment platform and encrypts the transaction order using the key contained in the configuration information. Common encryption methods include AES and RSA. Based on the payment channel associated with the merchant number, such as medical insurance payment, the aggregated payment platform invokes the corresponding payment plug-in, such as the medical insurance electronic voucher interface. The payment plug-in then calls the corresponding payment channel interface, encapsulates the encrypted order into a request message that complies with the channel's specifications (e.g., JSON format), and sends it to the payment server. Upon receiving the request message, the payment server uses the corresponding payment channel's public key or verification rules to decrypt and verify the encrypted order's legitimacy (e.g., amount consistency, merchant number validity, and signature correctness). If the encrypted order verification fails (e.g., the order amount has been tampered with), an error code is returned to the front-end, prompting the target user to "Payment information is incorrect, please re-order." If the encrypted order verification passes, the payment channel encapsulates the encrypted order parameters, including the order number, basic order information, and payment channel, into a standard format. Using standards such as QR codes, the structured data is converted into a black and white matrix pattern to generate a payment QR code.

[0023] S102. After the target user completes the aggregate payment through the payment QR code, a payment order is generated and stored in the payment database.

[0024] In this embodiment, after the target user completes the aggregated payment by scanning the payment QR code, the payment server sends a payment result notification to the callback address preconfigured by the aggregated payment platform in the payment channel. This notification includes information such as payment status, order amount, order number, timestamp, and signature value. Upon receiving the payment result notification, the aggregated payment platform uses the key agreed upon with the payment channel to calculate a signature for the callback parameters in the payment result notification (such as the order number, order amount, and timestamp). This signature is then compared with the signature value carried in the payment result notification to prevent data tampering. After verification, a fixed payment order template is used to generate a payment order. The payment order includes the payment order number, original transaction order number, merchant number, target user's ID, payment amount, patient name, registered department, and timestamp. Next, a "payment order table" is created in the payment database, containing the aforementioned order details. The payment order number is used as the primary key, and indexes are established, such as by merchant number, user ID, or payment order number, to facilitate quick search. Then, insert the data in the payment order into the payment order table, update the order status of the transaction order to "paid", and associate the payment order number to form an order link (for example, add the pay_order_id field in the transaction order table). Synchronously record the operation log of the payment order storage process (such as operation time, operator / system, IP address) to facilitate auditing and fault tracing.

[0025] S103. When the preset reconciliation time node is reached, all payment orders within the waiting reconciliation period are retrieved from the payment database, and all received orders within the waiting reconciliation period are queried through the received database. Order reconciliation is completed by combining all payment orders and received orders, and a number of abnormal users are output based on the order reconciliation results.

[0026] In this embodiment, based on the specific time of the pending reconciliation period, all payment orders and all receipt orders within the pending reconciliation period are batch-exported from the payment database and the hospital information center, respectively. Payment orders include payment order number, payment amount, patient name, registration department, payment time, etc., while receipt orders include receipt serial number, receipt amount, receipt time, and associated order number. A regular matching algorithm is then used to extract key payment data and key receipt data from all payment orders and receipt orders. Key payment data includes payment order number, payment amount, and payment time, while key receipt data includes receipt serial number, receipt amount, and receipt time. Synchronous sampling of all key payment data and key receipt data is completed within a preset time window, and based on the synchronous sampling results, several abnormal sub-periods within the pending reconciliation period are extracted.

[0027] The system then matches the associated order numbers in the key payment data for all abnormal sub-time periods with the payment order numbers in the key receipt data. Based on the matching results, the key payment data and key receipt data generated during the same transaction are integrated into a transaction dataset. A rule engine and hidden Markov model are then used to identify implicit abnormal orders and explicit abnormal bills within each abnormal sub-time period. Finally, the explicit and implicit abnormal orders are integrated to obtain all abnormal orders for the time period to be reconciled. The target users corresponding to the abnormal orders are marked as abnormal users.

[0028] In one embodiment, after receiving a payment request from a target user through an aggregated payment platform, calling a corresponding payment plug-in based on the payment request, and gradually generating a payment QR code through the payment plug-in include the following steps: After receiving the payment request from the target user through the aggregated payment platform, the order API service of the aggregated payment platform is called to create a transaction order based on the payment request; Retrieve the target user's identity, and verify the target user's transaction permissions based on the identity and the preset permission rule table; If the target user's permission verification passes, the target user's merchant number is calculated according to the fund allocation algorithm; According to the merchant number, the corresponding configuration information is obtained through the aggregated payment platform, and the transaction order is encrypted using the key in the configuration information to obtain the encrypted order; Call the corresponding payment plug-in according to the merchant number, send the encrypted order to the payment server of the aggregated payment platform through the payment plug-in, and use the payment server to verify the encrypted order; If the encrypted order verification passes, the payment server will generate a payment QR code based on the encrypted order.

[0029] In this embodiment, the aggregated payment platform establishes unified payment aggregation services and interface standards, providing a unified payment interface and backend management system. This eliminates the need to switch between multiple payment applications during the payment process; payment can be completed through a single aggregated payment platform. The aggregated payment platform also includes a payment plug-in management module and an order service module. The payment plug-in management module enables plug-in integration of various payment channels, such as WeChat, Alipay, bank cards, and medical insurance, to achieve aggregated payment. The order service module manages the security of core transaction processes, including order creation, payment application, payment confirmation, business application, and business confirmation. This module implements pre-payment application, verifies payment information for errors, and confirms payment after payment, ensuring a complete record of transaction elements.

[0030] When a target user clicks "pay" on the front-end (e.g., the payment interface of an online hospital mini-program), the aggregated payment platform immediately receives the target user's payment request and calls the order API service to create a transaction order. The transaction order includes a unique order number generated by the order API service for the transaction, such as the associated patient's medical number and fee details, which serves as a unique identifier for subsequent payment processes. It also contains basic order information, including the payment amount, patient name, and registered department. Next, the target user's identity, such as user ID, mobile phone number, and membership card number, is extracted from the payment request or user session. If the target user is not logged in, an identity authentication process may be triggered. Based on the target user's identity, the platform queries a pre-defined permission rule table, such as merchant level, user type, and transaction limit, to verify whether the target user has the required permissions for the current transaction. For example, whether high-frequency trading is prohibited or whether the single transaction amount limit has been exceeded. If the permission verification fails, such as if the single transaction limit has been exceeded, an error message is returned, terminating the process. If the target user's permission verification is passed, the corresponding merchant number will be matched through the preset fund allocation algorithm based on the patient's identity, treatment department, and service type (such as outpatient, inpatient, and medicine). For example, the outpatient registration fee will be allocated to the "hospital outpatient fee-dedicated merchant number", the drug fee will be allocated to the "hospital pharmacy merchant number", and the examination fee will be allocated to the "independent merchant number of the laboratory department", so as to realize the refined settlement of medical expenses by department and project type, which is convenient for the hospital's financial reconciliation and cost accounting.

[0031] Then, based on the merchant number, the corresponding configuration information is obtained through the aggregated payment platform, including keys, certificates, appid, etc. The key in the configuration information is used to encrypt the transaction order to obtain an encrypted order to ensure the security of patient privacy information in the transaction order (such as patient medical records, payment amounts, etc.) during transmission. Common encryption methods include the AES algorithm, the RSA algorithm, etc. Taking the AES encryption algorithm as an example, the initial key is first used to generate multiple round keys through a key scheduling algorithm (such as AES-128 generates 44 32-bit words), and then the first round key is used to perform an XOR operation on the transaction order, and the transaction order that completes the first round key XOR operation is subjected to multiple rounds of iterations (byte replacement, row shift, column confusion, round key addition) and the final round of processing to obtain the final encrypted order. Based on the payment channel associated with the merchant number, such as the medical insurance payment platform, the aggregated payment platform invokes the corresponding payment plug-in, such as the medical insurance electronic voucher interface. The merchant number is a hospital's unique identifier for various payment channels (such as UnionPay and the medical insurance payment platform). Merchant numbers vary across channels, so the aggregated payment platform can use the merchant number to determine which payment channel should be used for the current transaction. Furthermore, different payment channels have significant differences in interface specifications, parameter formats, and communication protocols. For example, some payment methods use APIv3, while UnionPay requires integration through the UnionPay Business Gateway. Therefore, the corresponding payment plug-in must be invoked based on the payment channel. The core function of the payment plug-in is to encapsulate the payment channel's API interface, enabling the aggregated payment platform to access channel capabilities (such as generating payment QR codes and verifying payment status), thus enabling secure communication between the aggregated payment platform and the payment channel. The aggregated payment platform then invokes the corresponding payment channel interface through the payment plug-in, encapsulating the encrypted order into a request message that complies with the channel's specifications (such as JSON format) and sending it to the payment server. The payment server is essentially the core transaction processing system for each payment channel, responsible for managing fund flow, verifying transaction legitimacy, and maintaining account data. After receiving the request message, the payment server uses the corresponding payment channel's public key or verification rules to decrypt and verify the legitimacy of the encrypted order (such as the consistency of the amount, the validity of the merchant number, and the correctness of the signature). If the encrypted order verification fails (for example, the order amount has been tampered with), an error code is returned to the front-end, prompting the target user to "Payment information is abnormal, please re-order." If the encrypted order verification passes, the payment channel encapsulates the encrypted order parameters, such as the order number, basic order information, and payment channel, into a standard format. Using standards such as QR codes, the structured data is converted into a black and white matrix pattern to generate a payment QR code.

[0032] In one embodiment, retrieving all payment orders in a waiting-for-reconciliation period from a payment database, querying all received orders in the waiting-for-reconciliation period from an received-for-reconciliation database, combining all payment orders and received orders to complete order reconciliation, and outputting a number of abnormal users based on the order reconciliation results includes the following steps: Retrieve all payment orders in the payment database within the waiting period for reconciliation, and query all received orders in the waiting period for reconciliation through the hospital information center; Based on the regular matching algorithm, key payment data and key account data are extracted from all payment orders and account arrival orders respectively; Complete the synchronous sampling of all key payment data and key account data through the preset time window, and extract several abnormal sub-time periods within the time period to be reconciled based on the synchronous sampling results; Complete data matching of key payment data and key account data for all abnormal sub-time periods to obtain multiple transaction data sets; For any abnormal sub-time period, the rule engine is used to check for explicit abnormal orders within the abnormal sub-time period. Use the hidden anomaly recognition model to complete the hidden state inference of the entire transaction data set, and determine the hidden abnormal orders in the time period to be reconciled based on the hidden state inference results; Combine all explicit abnormal orders and implicit abnormal orders to determine all abnormal orders in the time period to be reconciled, and output the corresponding abnormal users based on the abnormal orders.

[0033] In this embodiment, based on the specific time of the period to be reconciled, all payment orders and all receipt orders within the period to be reconciled are batch exported from the payment database and the hospital information center respectively. The payment order includes the payment order number, payment amount, patient name, registration department, payment time, etc., and the receipt order includes the receipt serial number, receipt amount, receipt time, associated order number, etc. Then, a regular matching algorithm is used to extract the key payment data and key receipt data from all payment orders and receipt orders respectively. The key payment data includes the payment order number, payment amount, and payment time, etc., and the key receipt data includes the receipt serial number, receipt amount, receipt time, etc. The regular matching algorithm is an algorithm used to search for strings that match a specific pattern in text. It can express complex matching rules concisely and efficiently through specific symbols and syntax. For example, the order number match: ^PAY\d{8}\d{5}$ matches a 13-digit order number starting with "PAY", the amount match: ^\d+(\.\d{2})?$ matches an integer or two-decimal amount, and the time match: ^\d{4}-\d{2}-\d{2}\d{2}:\d{2}:\d{2}$ matches the "YYYY-MM-DD HH:MM:SS" format.

[0034] Next, all key payment data and key account arrival data are synchronously sampled within a preset time window. Based on the synchronous sampling results, several abnormal sub-time periods within the time period to be reconciled are extracted. Specifically, historical reconciliation records are first queried through the hospital information center. These historical reconciliation records contain historical account arrival information, historical payment information, and transaction status. The target reconciliation data is then initially screened based on record completeness to obtain the target reconciliation data. The time difference between the payment timestamp and the account arrival timestamp in the target reconciliation data is used as the account arrival time difference. The mean and time difference of all account arrival time differences are then calculated. Outliers are removed from the total account arrival time difference based on the mean and time difference. The mean of all account arrival time differences after outlier removal is calculated to obtain the time mean. This time mean is used as the time compensation parameter between the key payment data and the key account arrival data. The key payment data and key account arrival data are sorted by timestamp based on their timestamps to obtain a time-series payment sequence and a time-series account arrival sequence. Next, the timestamps of the time-series payment or receipt sequences are adjusted using time compensation parameters. The adjusted timestamps of the time-series payment sequences are then aligned with those of the time-series receipt sequences. Transaction metrics for the offset-aligned time-series payment and receipt sequences are then synchronously collected using a preset time window. The size of the time window can be dynamically adjusted based on the transaction frequency of each sub-period within the time period to be reconciled. For sub-periods with higher transaction frequencies, smaller windows are used; conversely, for sub-periods with lower transaction frequencies, larger windows are used to prevent excessive data volume within a given time window. The window sliding step size can be set to half the window size (e.g., a 30-second step size for a 1-minute window) to ensure data overlap and avoid missing short-term anomalies. Transaction metrics include the total transaction amount and total transaction frequency of key payment and receipt data within each time window. For any time window, the difference in total transaction frequency and total transaction amount between the time-series payment and receipt sequences within the time window is first calculated. These differences are then weighted and combined to generate a comprehensive deviation index. Time windows whose comprehensive deviation index falls within the preset index threshold range (e.g., (0, 0.7)) are marked as abnormal time windows. After calculating the comprehensive deviation index, all abnormal windows are checked pairwise to see if there is time overlap or continuity between them. Abnormal windows with overlapping or continuous time are merged to obtain several consecutive abnormal windows. These consecutive abnormal windows are then used to determine several abnormal sub-time periods within the time period to be reconciled.

[0035] Data matching is performed based on the associated order numbers in the key payment data of all abnormal sub-time periods and the payment order numbers in the key account arrival data. When generating an account arrival order, in order to reduce the workload of subsequent reconciliation work, the account arrival order stores an associated order number that is exactly the same as the payment order number of the corresponding payment order. Therefore, direct matching can be performed, and the key payment data and key account arrival data generated in the same transaction process are integrated into a transaction data set.

[0036] Next, the overtly abnormal orders and bills within each abnormal sub-time period are identified. First, medical payment rules are obtained from multiple sources, such as internal hospital regulations and industry standards. Semantic analysis of these rules is then performed to extract core elements, including condition items, action items, rule types, and constraints. The extracted unstructured medical payment rules are then converted into structured rules, typically using a SON-like or XML-like structure. Specifically, the unstructured medical payment rules are first decomposed to extract their core elements. The unique identifier, rule name, detailed description of the rule, structured representation of the conditional expression, definition of the triggering action, and metadata (such as priority, applicable scenarios, and validity period) are defined for each rule. The rule engine's modular architecture is then constructed, including a parser, rule storage layer, matching engine, execution engine, and management interface. After the rule engine modular architecture is completed, an index is created based on rule condition fields (such as "payment amount" and "payment type"). When core order information is input, candidate rules are directly filtered using this index. A trigger mechanism is also defined to proactively trigger rule matching when core order information is input. After these steps, the final rule engine is obtained. All core order information is structured and sequentially input into the rules engine, which then outputs a structured report for each core order. The payment orders and receipt orders corresponding to the structured reports are then integrated to identify explicit abnormal orders. Explicit abnormalities in explicit abnormal orders primarily include discrepancies between the payment amount and the receipt amount, and inconsistent payment recipients for the same order.

[0037] Next, a hidden Markov model is used to identify hidden abnormal orders. Normal transaction data is first filtered from historical reconciliation records stored in the hospital information center. A hidden abnormality recognition model is then constructed. The model's hidden states are defined, and the number of states is set based on reconciliation experience. The model's parameters are initialized, including the initial state probability, state transition probability, and emission probability, completing the model's construction.

[0038] The training set is input into the latent anomaly recognition model. Using the expectation-maximization (EM) algorithm, the model parameters are iteratively updated to maximize the likelihood probability of the latent anomaly recognition model for the observed data. Training is completed when the latent anomaly recognition model outputs the maximum likelihood probability or reaches the preset maximum number of iterations. After extracting transaction features from the entire transaction dataset, these features are integrated chronologically to obtain a transaction observation sequence. All transaction observation sequences are sequentially input into the trained latent anomaly recognition model, and a forward algorithm is used to calculate the joint probability of each transaction observation sequence in the latent anomaly recognition model. Transaction observation sequences with a joint probability less than a preset probability threshold are marked as anomalous observation sequences. Finally, the payment orders and receipt orders corresponding to the anomalous observation sequences are marked as latent anomaly orders.

[0039] The implicit anomaly identification model primarily identifies hidden anomalies that are difficult to identify using rule engines. Examples include instances where a target user makes multiple payments within a short period of time, or where the payment arrives before the payment is made within the same transaction. These anomalies could be caused by a malfunction in the aggregated payment platform, resulting in errors in the generated payment or receipt bills. Alternatively, they could be due to unusual behavior by the target user, such as repeated payments, which could indicate scalping. These hidden anomalies are easily missed by rule engines, so a hidden Markov model is used to identify them. Finally, the explicit and implicit abnormal orders are combined to identify all abnormal orders during the time period to be reconciled. The target users corresponding to these abnormal orders are then marked as abnormal users.

[0040] After outputting abnormal users, the following steps are also included: For any abnormal user, collect multi-source transaction information of the abnormal user, which includes user transaction data, payment device data, user behavior data and user payment logs; Complete entity association and sequence alignment of multi-source transaction information to generate a multi-dimensional anomaly map; Taking the abnormal order node in the multidimensional anomaly map as the starting point, a bidirectional random walk is performed in the multidimensional anomaly map, and the initial anomaly propagation path in the multidimensional anomaly map is extracted based on the results of the bidirectional random walk; Utilizing a graph pruning algorithm to prune the initial anomaly propagation path to obtain an anomaly propagation subgraph; Extracting the initial abnormal nodes of the abnormal propagation subgraph, determining the causal relationship between the initial abnormal nodes using a causal discovery algorithm, and calculating the causal effect strength of the initial abnormal nodes based on the causal relationship extraction results; According to the strength of the causal effect, several key abnormal nodes are screened out from the initial abnormal nodes, and payment optimization prompt information is generated based on all key abnormal nodes.

[0041] Specifically, after identifying all abnormal users, the distributed data collection engine first synchronously acquires multi-source transaction information. This includes user transaction data such as payment orders, payment channel callback records, and medical insurance reimbursement details, obtained through the aggregated payment platform API. User behavior data such as abnormal user operation trajectories is collected through the front-end tracking SDK. System log data (user payment logs) such as payment interface call logs are extracted from the hospital information center server. Payment device data such as device fingerprints, network IP addresses, and geographic locations are obtained through the mobile SDK. In the preprocessing phase, ETL tools are used to complete steps such as structured data standardization, semi-structured log parsing, unstructured trajectory data vectorization, and missing value processing.

[0042] Multi-source entity recognition is then performed on the multi-source transaction information. First, unique identifiers (such as user IDs and order IDs) are directly associated to form the core nodes of a multi-dimensional anomaly graph. For example, each order ID corresponds to an order entity, which contains attributes such as amount and payment time. Implicit information is then mined from the multi-source transaction information. For example, a "large transaction" entity is generated based on a transaction amount threshold (e.g., ≥500 yuan), or an "abnormal operation" entity is identified based on the interaction duration in abnormal user operation traces. Contextual information such as time and space is combined with multi-source transaction information to generate entities, such as a "peak period" entity between 10:00 AM and 11:30 AM daily, or a "remote login" entity based on the device's geographic location. In the entity feature extraction phase, in addition to the original attributes, dynamic features (such as device IP change frequency and user anomaly rate) are calculated and normalized to eliminate dimensional differences. After multi-source entity recognition, the multi-source transaction information (such as user behavior data and payment logs) is parsed to extract associations. For example, from "payment failed due to system timeout," the causal relationship "payment failed - caused by... - system timeout" can be identified. A rule engine can also be used to define strong relationships between well-defined entities, such as "user - [initiate payment] - order." Attribute mapping and standardization are performed on identified entities, such as user, order, device, and system component, and their corresponding relationships, such as payment and attribution. Data is categorized into different types: numerical values, such as the amount of 580.50 yuan and the timestamp of 16:22:30; enumerations, such as payment statuses of pending, paid, and refunded; and textual data, such as the error message "amount inconsistent." Time data is uniformly converted to UTC timestamps, such as 2024-08-05 16:22:30 being converted to 1712372550. This standardization ensures consistent data formats across different sources, facilitating subsequent analysis. Knowledge fusion and alignment are then performed. Through entity alignment, unique identifiers such as user IDs and order numbers are used to link the same entity across different data sources. For example, records from different transactions for the same user can be linked. After completing the above steps, the relationships between entities are stored and represented as a graph. Graph databases such as Neo4j are used to store nodes and relationships. Nodes contain basic information and feature vectors. For example, user nodes contain basic information such as user ID and name, as well as behavioral feature vectors. Edge weights are dynamically calculated using an attention mechanism based on transaction frequency, transaction amount, and other factors. This allows the resulting multidimensional anomaly graph to reflect the strength and dynamics of relationships between entities.

[0043] After constructing the multidimensional anomaly graph, a bidirectional random walk is performed, starting from the abnormal order node in the graph, to calculate the anomaly propagation probability. The bidirectional random walk starts from the abnormal order node and walks in both the past and future time directions, exploring all possible paths associated with the abnormal order node. During each step, the probability of selecting the next node is determined based on the edge weights. The edge weight calculation takes into account various factors, such as temporal correlation (e.g., the edge weight for transactions within the past 30 minutes is multiplied by 1.5), business correlation (e.g., the edge weight for orders from the same department is multiplied by 1.2), and historical anomalies (e.g., the edge weight for previously generated anomalies is multiplied by 1.8). The anomaly propagation probability is calculated based on the transition probability at each step. Starting from the starting point, for each edge passed, the edge weight is multiplied by the probability of the current path to obtain a new anomaly propagation probability. For example, if the path is "abnormal order → user → device" and the edge weight for "abnormal order → user" is 0.9 and the edge weight for "user → device" is 0.8, then the anomaly propagation probability for this path is 0.9 × 0.8 = 0.72. The initial abnormal propagation path is generated by traversing all possible paths (the maximum number of walking steps is set to 5 steps), and the abnormal propagation probability of all possible initial abnormal propagation paths is calculated.

[0044] Next, a graph pruning algorithm is used to remove irrelevant nodes and edges from the initial anomaly propagation path according to preset rules. For example, nodes unrelated to the current anomaly type (non-received payment), such as nodes for treatments in other departments, are removed, as is edges with an anomaly propagation probability below 0.5, to reduce noise. Taking the initial anomaly propagation paths "order → user → device" and "order → payment channel → system interface" as examples, the algorithm checks whether nodes in these paths are related to the anomaly. If the path "order → user → patient → other order" exists in this initial anomaly propagation path and no anomalies exist in other orders, the branch is removed. After pruning, paths with an anomaly propagation probability greater than or equal to a preset probability threshold (e.g., 0.7) are retained to form the anomaly propagation subgraph.

[0045] Next, the initial anomaly nodes in the anomaly propagation subgraph are extracted, such as abnormal orders, abnormal users, abnormal devices, and abnormal payment channels. A causal discovery algorithm is then used to determine the causal relationships between these initial anomaly nodes and calculate the strength of the causal effect. A commonly used causal discovery algorithm is the PC algorithm. Specifically, a variable set is constructed based on the anomaly propagation nodes. A conditional independence test is performed on each pair of variables in the variable set. A chi-square test can be used to determine whether two variables are independent given other variables. For example, a test can be performed to determine whether "system interface anomaly" and "order anomaly" are independent given "payment channel anomaly." If two variables are independent under a certain set of conditions, the edge between them is deleted. Causal directions are determined using V-structures (e.g., A→B←C) and directional rules (e.g., preventing loops). For example, if "system interface anomaly → payment channel anomaly → order anomaly" is found, a causal chain is formed, thus revealing the causal relationship between the nodes. Next, based on the causal relationship extraction results, the causal effect strength of the initial anomaly node is calculated. Causal effect strength is a quantitative indicator used to measure the degree of influence of the causal variable on the outcome variable in a causal relationship. Its core purpose is to characterize the magnitude of change in the outcome variable when the causal variable is intervened (i.e., actively changed). For example, consider the variable set [order anomaly (Y), user anomaly (X1), device anomaly (X2), payment channel anomaly (X3), system interface anomaly (X4)]. Next, a control group is set up: the intervention group includes 120 transactions with X4 (system interface timeout), of which 96 (80%) experienced Y. The control group includes 120 transactions without X4 but with similar other characteristics, of which 24 (20%) experienced Y. The causal effect strength of system interface timeout (X4) on the outcome variable Y is calculated as (ACE(X4→Y)=80%-20%=60%). Key anomaly nodes are screened based on the causal effect strength, such as by setting a threshold, and payment optimization prompts are generated based on these identified key anomaly nodes. Furthermore, to ensure the accuracy of subsequent screening of key anomaly nodes, the degree centrality and betweenness centrality of the initial anomaly node, as well as the probability of anomaly propagation reaching the initial anomaly node during a two-way random walk, are calculated based on the anomaly propagation subgraph. For each initial anomaly node, a weighted fusion is constructed based on the strength of the causal effect of the initial anomaly node on other initial anomaly nodes with which it has a causal relationship, the degree centrality and betweenness centrality of the initial anomaly node in the anomaly propagation subgraph, and the probability of anomaly propagation reaching the initial anomaly node during a two-way random walk. This yields a comprehensive strength index. Key anomaly nodes are screened based on this comprehensive strength index, specifically those with a comprehensive strength index exceeding a preset threshold. Payment optimization prompts are generated based on these selected key anomaly nodes. Maintenance personnel on the aggregated payment platform will then optimize the platform based on these payment optimization prompts.

[0046] In one embodiment, the steps of completing synchronous sampling of all key payment data and key account arrival data within a preset time window and extracting several abnormal sub-time periods within the time period to be reconciled based on the synchronous sampling results include the following: Retrieve historical reconciliation records from the hospital information center, calculate the time difference between the aggregated payment platform's arrival, and determine the time compensation parameters between key payment data and key arrival data based on the time difference; Sort the key payment data and key account arrival data by timestamp to obtain the time-series payment sequence and time-series account arrival sequence; Complete the timestamp offset alignment of all time-series payment sequences and time-series account arrival sequences according to the time compensation parameters; The transaction indicators of the offset-aligned time series payment sequence and time series account arrival sequence are synchronously collected through the preset time window, and several abnormal sub-time periods are screened out from the time period to be reconciled based on the transaction indicators.

[0047] In this embodiment, the hospital information center is equivalent to the hospital information system (HIS). It refers to a comprehensive information system that utilizes computer technology, network communication technology, and database management technology to collect, store, process, analyze, transmit, and share various types of hospital business data, thereby achieving informatization and digitalization of hospital management. It is the core infrastructure of modern hospital operations, covering the entire process of medical services, administrative management, and financial accounting. The hospital information center stores clinical diagnosis and treatment information, such as individual patient examination records, medication records, surgical schedules, and medical records; information on pharmaceutical and consumables, such as drug procurement, warehousing, delivery, and inventory information; and information on medical consumables applications and usage registrations; and financial reconciliation information, such as receipt orders and reconciliation records. Therefore, historical reconciliation records can be directly queried through the hospital information center. Historical reconciliation records include historical receipt information, historical payment information, and transaction status. When calculating the time difference between payments using historical reconciliation records, it is necessary to filter these records to obtain target reconciliation records for calculating the time difference between payments. This filter can be selected for target reconciliation records that are close to the current reconciliation time point and cover the entire reconciliation cycle. In addition, it is also necessary to ensure the integrity of the fields of the filtered target reconciliation records, that is, to include the complete transaction serial number, payment timestamp, arrival timestamp, transaction status, etc. This is to ensure that when the time compensation parameters are subsequently calculated, the transaction serial number can be associated with the historical payment information and the historical arrival information, and to ensure that the target reconciliation records are not misaligned. For example, if the historical payment information of transaction A is mistakenly matched to the historical arrival information of transaction B, the payment timestamp and arrival timestamp are the basic data for calculating the arrival time difference, which will only lead to the inability to calculate the arrival delay, that is, the arrival time difference. The transaction status includes payment success and payment failure. If the transaction status of the target reconciliation record is payment failure, it is abnormal data and cannot be used to calculate the arrival time difference.

[0048] After selecting target reconciliation records that meet the requirements, the time difference between the payment timestamp and the receipt timestamp in the target reconciliation data is used as the arrival time difference. The mean and time difference of all arrival time differences are then calculated. Outliers are removed from the total arrival time difference based on the mean and time difference. For example, arrival time differences greater than the mean + 2 × standard deviation are removed as outliers. This method eliminates outliers caused by special events such as network fluctuations and system failures, ensuring that the calculated arrival time difference reflects the arrival delays during normal transactions. The mean of all arrival time differences after outlier removal is then calculated to obtain the time mean, which is used as the time compensation parameter between key payment data and key arrival data.

[0049] Next, based on the timestamps in the key payment data and key account arrival data, the two are sorted by timestamp to obtain a time-series payment sequence and a time-series account arrival sequence. The timestamps of the time-series payment sequence and the time-series account arrival sequence are then adjusted using a time compensation parameter. For example, the time compensation parameter is used to adjust the timestamp of the time-series payment sequence by directly adding the time compensation parameter to the timestamp of the time-series payment sequence to obtain the adjusted timestamp. The adjusted timestamp of the time-series payment sequence is then aligned with the timestamp of the time-series account arrival sequence. Calculating the time compensation parameter plays a calibration role in the timestamp alignment process. Because the timestamps of key account arrival data are easily affected by fixed factors such as payment channels and bank clearing processes, as well as random factors such as network latency and system load, the timestamps of key payment data and key account arrival data generated during the same transaction process may shift. Specifically, the timestamps of the key account arrival data are later than those of the key payment data. For these reasons, before aligning the timestamps, it is necessary to quantify the time shift patterns of the key payment data and key account arrival data and calculate the time compensation parameter to align the originally unsynchronized time series data to a sequence with a unified time base.

[0050] Next, transaction metrics for the offset-aligned payment and receipt sequences are synchronously collected using a preset time window. The size of the time window can be dynamically adjusted based on the transaction frequency of each sub-period within the reconciliation period. For sub-periods with higher transaction frequencies, a smaller time window is used; conversely, for sub-periods with lower transaction frequencies, the time window is appropriately expanded to prevent excessive data volume within a given time window. The window sliding step size can be set to 1 / 2 the window size (e.g., a 1-minute window step size of 30 seconds) to ensure data overlap and avoid missing short-term anomalies.

[0051] Transaction indicators include the total transaction amount and total transaction frequency of key payment and receipt data within each time window. The total transaction amount includes the total payment amount and the total receipt amount, and the total transaction frequency includes the total payment frequency and the total receipt frequency. For any time window, the difference in total transaction frequency and total transaction amount between the time-series payment sequence and the time-series receipt sequence within the time window is first calculated. These differences are then weighted and combined to produce a comprehensive deviation index. Time windows where the comprehensive deviation index falls within a preset index threshold range (e.g., (0, 0.7)) are marked as abnormal time windows. Furthermore, when the comprehensive deviation index exceeds the upper limit of the preset index threshold range (e.g., 0.7), it indicates that a large transaction or a group of transactions have not been received. This triggers a reconciliation alert and immediately sends an alert to the aggregated payment platform, prompting maintenance personnel at the aggregated payment platform to conduct system troubleshooting. This includes checking payment interface logs, transaction records in the account and payment databases, and verifying any system errors (e.g., SQL timeouts, interface failures, but success displayed on the front end). Furthermore, anomaly tracing is performed for this time window. Specifically, key account and payment data within the time window are collated and verified. The bank statements and medical insurance reimbursement receipts of the relevant users are reviewed to confirm discrepancies between the actual amount received and the system records. Furthermore, the relevant users' paper receipts are checked to identify any manual entry errors (e.g., an extra zero entered in an amount). This allows the source of the anomaly to be identified as quickly as possible to prevent significant losses to the hospital.

[0052] After calculating the comprehensive deviation index, all abnormal windows are checked pairwise to see if there is any time overlap or continuity between them. Abnormal windows with time overlap or continuity are then merged to obtain several continuous abnormal windows. Based on these continuous abnormal windows, several abnormal sub-time periods within the time period to be reconciled are determined. By merging previously scattered abnormal time windows into continuous abnormal windows and merging previously isolated abnormal data into continuous abnormal data, anomalies between different abnormal time windows can be effectively correlated. For example, two abnormal time windows may be "payment anomalies" and "account arrival anomalies," respectively. After merging, the cross-window data within the continuous time period can be correlated to reveal the complete logic of "delayed account arrival," rather than an isolated single-point anomaly.

[0053] In one embodiment, synchronously collecting transaction indicators of offset-aligned time-series payment sequences and time-series account arrival sequences through a preset time window, and screening out several abnormal sub-time periods from a time period to be reconciled based on the transaction indicators, includes the following steps: Synchronously collect transaction indicators for time-series payment sequences and time-series account arrival sequences with aligned timestamps through pre-set time windows. Transaction indicators include the total transaction amount and total transaction frequency of key payment data and key account arrival data within each time window. For any time window, calculate the comprehensive deviation index of the time-series payment sequence and time-series account arrival sequence within the time window based on the transaction indicators; If the comprehensive deviation index is within the preset index threshold range, the time window is marked as an abnormal time window; Based on the timestamps of the abnormal time windows, the windows between the abnormal time windows are merged to obtain several consecutive abnormal windows. Several abnormal sub-time periods within the time period to be reconciled are then determined based on the consecutive abnormal windows. In this embodiment, a preset time window is first used to synchronously collect transaction metrics for the offset-aligned time-series payment sequence and the time-series receipt sequence. The size of the time window can be dynamically adjusted based on the transaction frequency of each sub-time period within the time period to be reconciled. For sub-time periods with higher transaction frequencies, a smaller time window is used. Conversely, for sub-time periods with lower transaction frequencies, the time window is appropriately expanded to prevent excessive data volume within a particular time window. For example, when the transaction frequency is greater than or equal to 120 transactions / minute, a system load warning is triggered, and the time window is reduced to ±30 seconds. When the transaction frequency is less than 120 transactions / minute, the time window is reduced to ±60 seconds. The window sliding step size of the time window can be set to 1 / 2 of the window size (e.g., a 30-second step size for a 1-minute window) to ensure data overlap and avoid missing short-term anomalies.

[0054] Transaction indicators include the total transaction amount and total transaction frequency of key payment data and key account arrival data within each time window. The total transaction amount includes the total payment amount and the total account arrival amount, and the total transaction frequency includes the total payment frequency and the total account arrival frequency. For any time window, the difference in total transaction frequency and total transaction amount between the time-series payment sequence and the time-series account arrival sequence within the time window is first calculated. Then, a weighted fusion is performed on these differences. Specifically, the dimensional difference between the difference in total transaction frequency and the difference in total transaction amount is first eliminated. This can be done using methods such as Z-Score normalization and extreme value normalization. Then, weights are assigned to the two and weighted fusion is performed to obtain a comprehensive deviation index. For example, the difference in total transaction frequency is 2, and the difference in total transaction amount is 165.7 yuan. Then, Z-Score standardization is used to eliminate the dimensional difference between the two (assuming the historical frequency standard deviation is 10 and the historical amount standard deviation is 500). The total transaction frequency difference is 0.2, and the total transaction amount difference is 0.3314. Then, the weight of the total transaction frequency difference is set to 0.4, and the weight of the total transaction amount difference is set to 0.6. The calculated comprehensive deviation index is 0.27884.

[0055] Time windows where the comprehensive deviation index falls within a preset threshold range (e.g., (0, 0.7)) are marked as abnormal time windows. When the comprehensive deviation index exceeds the upper limit of the preset threshold range (e.g., 0.7), it indicates that a large transaction or a group of transactions have not been received. This triggers a reconciliation alert and immediately sends an alert to the aggregated payment platform, prompting maintenance personnel at the aggregated payment platform to conduct system troubleshooting. This includes checking payment interface logs, transaction records in the account and payment databases, and verifying any system errors (e.g., SQL timeouts, interface failures, but success displayed on the front end). Furthermore, abnormality tracing is performed for this time window. Specifically, key account and payment data within the time window are collated and verified. The bank statements and medical insurance reimbursement receipts of the relevant users are reviewed to confirm discrepancies between the actual amount received and the system records. Furthermore, the relevant users' paper receipts are checked to identify any manual entry errors (e.g., an extra zero is entered for an amount). The source of the abnormality is identified as quickly as possible to prevent significant losses to the hospital.

[0056] After calculating the comprehensive deviation index, all abnormal windows are checked pairwise to see if there is any overlap or continuity between them. Overlapping or continuous abnormal windows are then merged to form several continuous abnormal windows. These continuous abnormal windows are then used to determine several abnormal sub-time periods within the reconciliation period. For example, if the abnormal time windows are [9:00-9:10], [9:05-9:15], [9:30-9:40], and [9:40-9:50], then [9:00-9:10] and [9:05-9:15] overlap and can be merged into the continuous abnormal window [9:00-9:15]. Since [9:30-9:40] and [9:40-9:50] are continuous, they can be merged into the continuous abnormal window [9:30-9:50]. Both [9:00-9:15] and [9:30-9:50] are considered abnormal sub-time periods. Merging the originally scattered abnormal time windows into continuous abnormal windows, and merging the originally isolated abnormal data into continuous abnormal data, can effectively associate the abnormalities between different abnormal time windows. For example, two abnormal time windows may be "payment abnormality" and "account arrival abnormality" respectively. After merging, the complete logic of "delayed arrival" can be discovered through cross-window data association within a continuous time period, rather than an isolated single point abnormality.

[0057] In one embodiment, detecting the explicit abnormal orders within the abnormal sub-time period based on the rule engine includes the following steps: Convert pre-acquired medical payment rules into structured rules and build a rule engine based on the structured rules; Use the template matching algorithm to extract the core order fields of all payment orders and receipt orders within the abnormal sub-time period, and then integrate all core order fields with the corresponding transaction data sets into multiple core transaction information; Input all core order information into the rule engine in sequence, verify the core transaction information through the rule engine, and output the engine verification results; Determine the explicit abnormal orders within the abnormal sub-time period based on the engine verification results.

[0058] In this embodiment, medical payment rules are first obtained from multiple sources, such as internal hospital regulations and industry standards. Semantic analysis of these rules is then performed to extract core elements, including conditions (prerequisites for triggering the rule, such as "payment amount > 5,000 yuan," "payment method: medical insurance pooling," and "order time on a non-working day"); actions (processing logic after the rule is triggered, such as "mark for review," "reconciliation rejection," and "generate an exception alert"); rule types (priority and application scenarios), such as "mandatory rules" (e.g., amount consistency check) and "alert rules" (e.g., high-frequency, small-value transactions); and constraints (rules) (scope of validity, such as "applicable only to outpatient payments" and "valid until December 2026." The extracted unstructured medical payment rules are then converted into structured rules, typically using a SON-like or XML-like structure. Specifically, the unstructured medical payment rules are first decomposed to extract their core elements. The rules' unique identifier, rule name, detailed description, structured representation of conditional expressions, triggering action definitions, and metadata (e.g., priority, applicable scenarios, and validity period) are defined. For example, a medical payment rule generates a risk alert and submits for financial review when the hospitalization deposit payment exceeds 10,000 yuan, or the payment method is a credit card and the payment time is between 10:00 PM and 6:00 AM. This breakdown yields the following: Condition 1: Payment Amount > 10,000 yuan; Condition 2: Payment Method = Credit Card; Condition 3: Payment Time Between 10:00 PM and 6:00 AM; Logical Relationship: (Condition 1) OR (Condition 2 AND Condition 3); Action: Generate Risk Alert + Submit for Financial Review; Constraint: Applicable to the hospitalization deposit payment scenario. The broken down and structured medical payment rule is then subjected to consistency checks, including syntax validation to ensure the JSON / XML format is correct and that no fields are missing; logical validation to check for inconsistencies in conditional expressions, such as "amount > 5,000 yuan and amount < 3,000 yuan"; and coverage verification to avoid gaps between rules, such as when no rule covers "amount = 5,000 yuan" or duplicate coverage, such as when two rules define different actions for the same condition.

[0059] Build the modular architecture of the rule engine, including a parser that converts structured rules into internal data structures the engine can process, such as rule trees and condition lists. A rule storage layer uses indexed structures (such as hash tables and prefix trees) to store rules, enabling fast retrieval and updates. A matching engine efficiently matches applicable rules based on the input core transaction information. An execution engine executes corresponding actions based on matching results and logs the execution. A management interface provides rule addition, deletion, modification, and querying, version control, and testing capabilities. After building the modular architecture of the rule engine, indexes are created based on rule condition fields (such as "payment amount" and "payment type"). When core order information is entered, candidate rules are directly filtered using the index. A trigger mechanism is also defined to proactively trigger rule matching when core order information is entered. After completing these steps, the final rule engine is obtained.

[0060] Since both payment orders and receipt orders are structured, fields are directly defined for these orders, based on reconciliation rules (e.g., amount consistency). These fields include payment status (successful / failed), payment channel (credit card / medical insurance, etc.), payment type (self-funded / pooled), and payment recipient (medication / examination). Based on these defined fields, core order fields are directly identified in both payment and receipt orders. All core order fields for the same target user are then integrated with the corresponding transaction dataset to form multiple core transaction records. These core transaction records are then fed into the rules engine. Upon startup, the rules engine loads pre-configured structured rules (e.g., a JSON-like rule set). For each core transaction record, the rules engine iterates through all rules in order of priority. When a core transaction record meets a rule's exception criteria, the rules engine marks the corresponding exception type (e.g., "amount_mismatch" or "unilateral_account") in the results and records the exception details (e.g., specific field value, violated rule number, verification time, etc.). If multiple rules are met simultaneously, the results summarize all matching exception types. The identified core transactions with anomalies are summarized by time period and anomaly type to generate a structured report (e.g., a list containing order ID, anomaly type, rule number, and field details). This structured report is then stored in the abnormal transaction database for subsequent tracing and statistical analysis. The payment orders and receipt orders corresponding to the structured report are then integrated to identify explicit abnormal orders. Explicit abnormalities in explicit abnormal orders primarily include discrepancies between payment and receipt amounts, and inconsistent payment recipients for the same order.

[0061] In one embodiment, using a latent anomaly recognition model to complete latent state inference of all transaction data sets and determining latent abnormal orders in a time period to be reconciled based on the latent state inference results includes the following steps: Filter out normal transaction data from historical reconciliation records, which are stored in the hospital information center; Normal transaction data is used as a training set, and unsupervised learning is used to train the latent anomaly recognition model until the latent anomaly recognition model outputs the maximum likelihood probability. The latent anomaly recognition model is built based on the hidden Markov model; Construct the transaction observation sequence of the entire transaction data set; All transaction observation sequences are sequentially input into the trained implicit anomaly recognition model, and the joint probability of each transaction observation sequence in the implicit anomaly recognition model is calculated through the forward algorithm; The transaction observation sequences whose joint probability is less than the preset probability threshold are marked as abnormal observation sequences, and the implicit abnormal orders of all abnormal sub-time periods are determined based on the abnormal observation sequences.

[0062] In this embodiment, normal transaction data is first screened from historical reconciliation records stored in the hospital information center. Normal transaction data refers to historical core transaction information that has not been marked as abnormal by the rule engine or the implicit anomaly recognition model and for which the historical reconciliation result is successful. The implicit anomaly recognition model is based on the Hidden Markov Model (HMM), a probabilistic time series model whose core concept is to infer the underlying invisible state sequence (such as the corresponding phonemes in speech or the parts of speech in text) from the observed data sequence (such as speech signals or text). Historical observation features are extracted from the historical core transaction information. These historical observation features include numerical features (such as payment amount, such as the time difference between receipt and payment time, and transaction frequency); temporal features (such as the time period of the transaction); and categorical features (such as payment channel (one-hot encoding) and business type (such as outpatient payment and hospitalization deposit). These numerical features are normalized to ensure stable convergence of the HMM model. The extracted historical observation features are then integrated into a feature sequence, which serves as the training set for the HMM model.

[0063] Next, we build a latent anomaly recognition model. We first define its hidden states, which represent the latent pattern categories of transactions. Based on reconciliation experience, we set the number of states, N (e.g., N=3), to include, for example, S1: normal high-frequency, small-value transactions (e.g., outpatient registrations), S2: normal large-value, low-frequency transactions (e.g., hospitalization deposits), and S3: normal periodic transactions (e.g., daily medical insurance settlement periods). We also define a transaction observation sequence, which is the feature vector of the transaction dataset, for example, [amount normalization value, frequency normalization value, payment channel code, transaction period code]. We then initialize the parameters of the latent anomaly recognition model, including its initial state probability, state transition probability, and emission probability, completing the construction of the latent anomaly recognition model.

[0064] The training set is input into the latent anomaly recognition model. Using the expectation-maximization (EM) algorithm, the model parameters are iteratively updated to maximize the likelihood of the latent anomaly recognition model for the observed data. The expectation-maximization (EM) algorithm is a type of optimization algorithm that uses iterative maximum likelihood estimation. It optimizes model parameters by alternating between expectation steps (E-steps) and maximization steps (M-steps). The expectation step calculates the expected value of the conditional probability distribution of each data point with respect to the latent variables, given the current model parameters. This step "expects" the value of the latent variables if the model parameters are known. Formally, this step calculates the expected value of the complete data log-likelihood function (which takes into account the likelihood of the latent variables). The maximization step (M-step) uses the expected values ​​obtained in the E-step as weights to re-estimate the model parameters to maximize this weighted complete data log-likelihood function. Training of the latent anomaly recognition model is completed when the maximum likelihood probability is output or when the preset maximum number of iterations is reached.

[0065] After extracting transaction features from the entire transaction dataset, these features are integrated chronologically to generate a transaction observation sequence. Transaction features include standardized amounts, standardized frequencies, payment channel codes, and transaction time codes. The standardized amount refers to the normalized difference between the payment amount and the total transaction amount; the standardized frequency refers to the normalized difference between the total transaction frequency; the payment channel code refers to the code for the payment channel selected by the target user; and the transaction time code refers to the difference between the payment time and the receipt time. All transaction observation sequences are sequentially input into the trained hidden anomaly recognition model, and the forward algorithm is used to calculate the joint probability of each transaction observation sequence within the hidden anomaly recognition model. The forward algorithm is a dynamic programming algorithm primarily used to calculate the probability of a given observation sequence within a hidden Markov model. Specifically, the forward algorithm calculates the total probability of a transaction observation sequence, that is, the joint probability of all possible hidden state sequences. Transaction observation sequences with a joint probability less than a preset probability threshold are marked as anomalous. The probability threshold can be determined based on the joint probability distribution of historical normal transaction data, such as the mean of the joint probability minus three times the standard deviation of the joint probability. Finally, the payment orders and receipt orders corresponding to the abnormal observation sequences are marked as hidden abnormal orders.

[0066] The hidden anomaly recognition model identifies hidden anomalies that are difficult to identify using rule engines. For example, a target user may make multiple payments within a short period of time, or the payment time may be earlier than the payment time during the same transaction. These anomalies may be caused by a malfunction of the aggregated payment platform, resulting in errors in the generated payment or receipt bills. Alternatively, the target user may exhibit unusual behavior, such as repeated payments, which may indicate scalping. These hidden anomalies are easily missed by rule engines, so hidden Markov models are used for hidden anomaly recognition.

[0067] In one embodiment, the method further comprises the steps of: For any abnormal user, the hospital information center will query the abnormal user's medical resource consumption and calculate the abnormal user's medical payment amount based on the medical resource consumption; Calculate the medical payment amount of the abnormal user based on the incoming orders and payment orders corresponding to the abnormal user; If the amount of medical expenses to be paid is greater than the amount of medical expenses already paid, a payment reminder message will be sent to the abnormal user; If the amount of medical expenses to be paid is less than the amount of medical expenses already paid, a medical refund strategy will be generated based on the pre-acquired fund risk control rules.

[0068] In this embodiment, the hospital information center queries the medical resource consumption of each abnormal user. This consumption includes examination items (such as CT scans and blood tests), medications, and treatment procedures (such as surgery and infusions). The hospital's fee rules are used to calculate the current fee payable by the abnormal user, i.e., the outstanding medical fee. The abnormal user's paid medical fee, i.e., the fee already paid by the target user, is then calculated based on the abnormal user's corresponding incoming and outgoing payment orders. If the outstanding medical fee is greater than the paid medical fee, it indicates that the abnormal user has underpaid. Therefore, a payment reminder is sent to the target user through the patient side of the online hospital system. Furthermore, if the target patient objects to this payment reminder, they can submit a review request to the online hospital system through the patient side. For example, a patient may have completed a payment on an aggregated payment platform, but the hospital information center may not have received the payment information in a timely manner, resulting in a one-sided account. If the outstanding medical fee is less than the paid medical fee, it indicates that the target user may have made duplicate payments. Therefore, a medical refund policy is generated and the refund is processed according to the refund policy. The specific method for generating a medical refund strategy includes: first obtaining the hospital's financial risk control rules, which include the average daily refund amount, single refund amount, and refund channel, etc. First, all target users who need to execute the refund process are integrated, and the amount to be refunded for each target user is calculated separately, and the total refund amount is calculated. If the total refund amount is less than or equal to the average daily refund amount, and the amount to be refunded for each target user is less than or equal to the single refund amount, the refund process is executed and the refund is made according to the original payment channel of each target user. If the total refund amount is less than or equal to the average daily refund amount, but the amount to be refunded for a target user is greater than the single refund amount, the amount to be refunded for the target user needs to be approved, the identity of the target user is confirmed, and the amount to be refunded is recalculated. If approved, the amount to be refunded for the target user is split and refunded according to the single refund amount. If the total refund amount is greater than or equal to the average daily refund quota, refunds will be made in sequence according to the payment time of each target user. When the average daily refund quota is reached, the refund process for the remaining amount will continue the next day until the refund process for all target users is completed.

[0069] The present application also provides a machine-readable storage medium having instructions stored thereon, the instructions being used to enable a machine to execute the method for real-time verification of transaction data based on multiple payment channels according to any one of the above items.

[0070] This application also provides a real-time transaction data verification system based on multiple payment channels, including: a memory configured to store instructions; and A processor is configured to call instructions from a memory and implement the method for real-time verification of transaction data based on multiple payment channels according to any one of the above items when executing the instructions.

[0071] Among them, the processor can adopt a central processing unit (CPU). Of course, according to actual usage, other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. can also be adopted. The general-purpose processor can adopt a microprocessor or any conventional processor, etc., and this application does not impose any restrictions on this.

[0072] Among them, the memory can be an internal storage unit of a computer device, such as a hard disk or memory of a computer device, or an external storage device of a computer device, such as a plug-in hard disk, smart memory card (SMC), secure digital card (SD) or flash memory card (FC) equipped on the computer device. In addition, the memory can also be a combination of an internal storage unit and an external storage device of a computer device. The memory is used to store computer programs and other programs and data required by the computer device. The memory can also be used to temporarily store data that has been output or is to be output. This application does not impose any restrictions on this.

[0073] An embodiment of the present application also provides a machine-readable storage medium having instructions stored thereon, the instructions being used to enable a machine to execute the above-mentioned method for real-time verification of transaction data based on multiple payment channels.

[0074] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0075] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0076] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0077] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

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

[0079] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0080] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can be implemented using any method or technology for information storage. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0081] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0082] The above are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included within the scope of the claims of the present application.

Claims

1. A real-time verification method for transaction data based on multiple payment channels, characterized in that: Applied to an online hospital system, the online hospital system includes an aggregated payment platform and a hospital information center, the aggregated payment platform and the hospital information center are communicatively connected, and the hospital information center includes a payment database and an account arrival database. The method includes the following steps: After receiving the payment request from the target user through the aggregated payment platform, the corresponding payment plug-in is called based on the payment request, and the payment QR code is generated by the payment plug-in; When the target user completes the aggregate payment through the payment QR code, a payment order is generated and stored in the payment database; When the preset reconciliation time node is reached, all payment orders within the reconciliation period are retrieved from the payment database, and all received orders within the reconciliation period are queried through the received database. The order reconciliation is completed by combining all payment orders and received orders, and a number of abnormal users are output based on the order reconciliation results.

2. The method according to claim 1, characterized in that After receiving the payment request of the target user through the aggregate payment platform, calling the corresponding payment plug-in based on the payment request and generating a payment QR code through the payment plug-in include the following steps: After receiving the payment request from the target user through the aggregated payment platform, the order API service of the aggregated payment platform is called to create a transaction order based on the payment request; Retrieve the target user's identity, and verify the target user's transaction permissions based on the identity and the preset permission rule table; If the target user's permission verification passes, the target user's merchant number is calculated according to the fund allocation algorithm; According to the merchant number, the corresponding configuration information is obtained through the aggregated payment platform, and the transaction order is encrypted using the key in the configuration information to obtain the encrypted order; Call the corresponding payment plug-in according to the merchant number, send the encrypted order to the payment server of the aggregated payment platform through the payment plug-in, and use the payment server to verify the encrypted order; If the encrypted order verification passes, the payment server will generate a payment QR code based on the encrypted order.

3. The method according to claim 1, wherein The method of retrieving all payment orders in the waiting reconciliation period from the payment database, querying all incoming orders in the waiting reconciliation period from the incoming orders database, combining all payment orders and incoming orders to complete order reconciliation, and outputting a number of abnormal users based on the order reconciliation results includes the following steps: Retrieve all payment orders in the payment database within the waiting period for reconciliation, and query all received orders in the waiting period for reconciliation through the hospital information center; Based on the regular matching algorithm, key payment data and key account data are extracted from all payment orders and account arrival orders respectively; Complete the synchronous sampling of all key payment data and key account data through the preset time window, and extract several abnormal sub-time periods within the time period to be reconciled based on the synchronous sampling results; Complete data matching of key payment data and key account data for all abnormal sub-time periods to obtain multiple transaction data sets; For any abnormal sub-time period, the rule engine is used to check for explicit abnormal orders within the abnormal sub-time period. Use the hidden anomaly recognition model to complete the hidden state inference of the entire transaction data set, and determine the hidden abnormal orders in the time period to be reconciled based on the hidden state inference results; Combine all explicit abnormal orders and implicit abnormal orders to determine all abnormal orders in the time period to be reconciled, and output the corresponding abnormal users based on the abnormal orders.

4. The method according to claim 3, characterized in that The method of completing the synchronous sampling of all key payment data and key account arrival data through a preset time window and extracting several abnormal sub-time periods within the time period to be reconciled based on the synchronous sampling results includes the following steps: Retrieve historical reconciliation records from the hospital information center, calculate the time difference between the aggregated payment platform's arrival, and determine the time compensation parameters between key payment data and key arrival data based on the time difference; Sort the key payment data and key account arrival data by timestamp to obtain the time-series payment sequence and time-series account arrival sequence; Complete the timestamp offset alignment of all time-series payment sequences and time-series account arrival sequences according to the time compensation parameters; The transaction indicators of the offset-aligned time series payment sequence and time series account arrival sequence are synchronously collected through the preset time window, and several abnormal sub-time periods are screened out from the time period to be reconciled based on the transaction indicators.

5. The method according to claim 4, characterized in that The synchronous collection of transaction indicators of the offset-aligned time series payment sequence and time series account arrival sequence through a preset time window, and screening out several abnormal sub-time periods from the time period to be reconciled based on the transaction indicators, includes the following steps: Synchronously collect transaction indicators for time-series payment sequences and time-series account arrival sequences with aligned timestamps through pre-set time windows. Transaction indicators include the total transaction amount and total transaction frequency of key payment data and key account arrival data within each time window. For any time window, calculate the comprehensive deviation index of the time-series payment sequence and time-series account arrival sequence within the time window based on the transaction indicators; If the comprehensive deviation index is within the preset index threshold range, the time window is marked as an abnormal time window; Based on the timestamps of the abnormal time windows, the windows between the abnormal time windows are merged to obtain several consecutive abnormal windows, and several abnormal sub-time periods within the time period to be reconciled are determined based on the consecutive abnormal windows.

6. The method according to claim 3, characterized in that The method of checking for explicit abnormal orders within the abnormal sub-time period based on the rule engine includes the following steps: Convert pre-acquired medical payment rules into structured rules and build a rule engine based on the structured rules; Use the template matching algorithm to extract the core order fields of all payment orders and receipt orders within the abnormal sub-time period, and then integrate all core order fields with the corresponding transaction data sets into multiple core transaction information; Input all core order information into the rule engine in sequence, verify the core transaction information through the rule engine, and output the engine verification results; Determine the explicit abnormal orders within the abnormal sub-time period based on the engine verification results.

7. The method according to claim 3, characterized in that The method of using the latent anomaly recognition model to complete the hidden state inference of the entire transaction data set and determining the latent abnormal orders in the time period to be reconciled based on the hidden state inference results includes the following steps: Filter out normal transaction data from historical reconciliation records, which are stored in the hospital information center; Normal transaction data is used as a training set, and unsupervised learning is used to train the latent anomaly recognition model until the latent anomaly recognition model outputs the maximum likelihood probability. The latent anomaly recognition model is built based on the hidden Markov model; Construct the transaction observation sequence of the entire transaction data set; All transaction observation sequences are sequentially input into the trained implicit anomaly recognition model, and the joint probability of each transaction observation sequence in the implicit anomaly recognition model is calculated through the forward algorithm; The transaction observation sequences whose joint probability is less than the preset probability threshold are marked as abnormal observation sequences, and the implicit abnormal orders of all abnormal sub-time periods are determined based on the abnormal observation sequences.

8. The method according to claim 1, characterized in that The method further comprises the steps of: For any abnormal user, the hospital information center will query the abnormal user's medical resource consumption and calculate the abnormal user's medical payment amount based on the medical resource consumption; Calculate the medical payment amount of the abnormal user based on the incoming orders and payment orders corresponding to the abnormal user; If the amount of medical expenses to be paid is greater than the amount of medical expenses already paid, a payment reminder message will be sent to the abnormal user; If the amount of medical expenses to be paid is less than the amount of medical expenses already paid, a medical refund strategy will be generated based on the pre-acquired fund risk control rules.

9. A machine-readable storage medium, characterized in that The machine-readable storage medium stores instructions for causing a machine to execute the method for real-time verification of transaction data based on multiple payment channels according to any one of claims 1 to 8.

10. A real-time transaction data verification system based on multiple payment channels, characterized in that: include: a memory configured to store instructions; as well as A processor is configured to call instructions from a memory and implement the method for real-time verification of transaction data based on multiple payment channels according to any one of claims 1 to 8 when executing the instructions.

Images