Real-time verification method and system for transaction data based on multiple payment channels

Abstract

The application discloses a kind of based on the real-time verification method of transaction data of multiple payment channels, it is related to data verification field, its method includes: calling corresponding payment plug-in, and generating payment two-dimensional code;After completing aggregated payment, generate payment order, and store payment order to payment database;Call all payment orders in the payment database in the time period to be reconciled, and complete order reconciliation by querying all payment orders and arrival order, and output several abnormal users according to order reconciliation result;Query the medical resource consumption of all abnormal users, output abnormal processing strategy in combination with medical resource consumption and pre-acquired fund risk control rule.The application can effectively improve reconciliation efficiency and reconciliation accuracy.

Description

TECHNICAL FIELD

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

[0002] With the wide application of information technology in the medical field, more and more hospitals have begun to introduce diversified payment methods to improve the patient's medical experience and the hospital's operational efficiency. However, diversified payment methods have increased the workload and complexity of reconciliation, which may lead to omissions in the reconciliation process and fail to detect abnormal payment conditions such as unilateral accounts and repeated payments in the payment process in a timely manner, thereby affecting the patient's medical experience and the hospital's operational efficiency.

[0003] The existing reconciliation method mainly uses automatic or semi-automatic tools by the hospital financial department to reconcile with each payment platform one by one, but this reconciliation method greatly increases the reconciliation workload and affects the reconciliation efficiency, especially for some large hospitals, which seriously affects their normal operation. In addition, for some orders paid through multiple channels, misjudgment is easy to occur, which affects the patient's medical experience. SUMMARY

[0004] Embodiments of the present application provide a transaction data real-time verification method and system based on multiple payment channels, which are used to solve the problem that the prior art cannot achieve efficient and accurate reconciliation.

[0005] To achieve the above-mentioned purpose, the embodiments of the present application adopt the following technical solutions:

[0006] In a first aspect, a transaction data real-time verification method 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 connection, the hospital information center includes a payment database and a payment database, and the method includes:

[0007] 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 the payment two-dimensional code is generated through the payment plug-in;

[0008] When the target user completes the aggregated payment through the payment two-dimensional code, a payment order is generated, and the payment order is stored in the payment database;

[0009] When reaching the preset reconciliation time node, all payment orders in the to-be-reconciled time period in the payment database are called, and all to-be-reconciled time period orders are queried through the payment database, the order reconciliation is completed in combination with all payment orders and to-be-reconciled time period orders, and a plurality of abnormal users are output according to the order reconciliation result.

[0010] Optionally, after receiving a payment request from a target user through the aggregated payment platform, the corresponding payment plugin is invoked based on the payment request, and a payment QR code is generated through the payment plugin, including the following steps:

[0011] After receiving a payment request from a target user through the aggregated payment platform, the platform's order API service is invoked to create a transaction order based on the payment request.

[0012] Retrieve the target user's identity identifier and verify the target user's transaction permissions based on the identity identifier and a preset permission rule table;

[0013] If the target user's permissions are verified, the target user's merchant ID is calculated according to the fund allocation algorithm;

[0014] Based on 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;

[0015] The corresponding payment plugin is invoked based on the merchant ID, and an encrypted order is sent to the payment server of the aggregated payment platform through the payment plugin. The payment server then verifies the encrypted order.

[0016] If the encrypted order is verified, a payment QR code will be generated by the payment server based on the encrypted order.

[0017] Optionally, retrieve all payment orders from the payment database within the reconciliation period, and query all incoming orders from the invoice database within the reconciliation period. Combine all payment orders and incoming orders to complete order reconciliation, and output several abnormal users based on the order reconciliation results, including the following steps:

[0018] Retrieve all payment orders from the payment database that are pending reconciliation period, and query all received orders that are pending reconciliation period through the hospital information center;

[0019] Based on the regular expression matching algorithm, key payment data and key receipt data were extracted from all payment orders and receipt orders respectively;

[0020] The system completes the synchronous sampling of all key payment data and key receipt data within a preset time window, and extracts several abnormal sub-time periods within the reconciliation period based on the synchronous sampling results.

[0021] Complete the data matching of key payment data and key receipt data for all abnormal sub-time periods to obtain multiple transaction datasets;

[0022] For any abnormal sub-time period, the explicit abnormal orders within the abnormal sub-time period are identified based on the rule engine;

[0023] The hidden state inference of the entire transaction data set is completed by using the implicit anomaly identification model, and the hidden state inference result is used to determine the implicit abnormal order in the reconciliation time period to be reconciled.

[0024] The entire abnormal order in the reconciliation time period to be reconciled is determined in combination with the entire explicit abnormal order and the implicit abnormal order, and the corresponding abnormal user is output according to the abnormal order.

[0025] Optionally, the synchronization sampling of the entire key payment data and key account data is completed through a preset time window, and a plurality of abnormal sub-time periods in the reconciliation time period to be reconciled are extracted according to the synchronization sampling result, including the following steps:

[0026] The historical reconciliation records of the hospital information center are called, the account time difference of the aggregation payment platform is calculated according to the historical reconciliation records, and the time compensation parameter between the key payment data and the key account data is determined according to the account time difference;

[0027] The key payment data and the key account data are sorted according to the time stamp to obtain the time sequence payment sequence and the time sequence account sequence;

[0028] The time stamp offset alignment of the entire time sequence payment sequence and the time sequence account sequence is completed according to the time compensation parameter;

[0029] The transaction indicators of the offset-aligned time sequence payment sequence and the time sequence account sequence are synchronously collected through a preset time window, and a plurality of abnormal sub-time periods are screened from the reconciliation time period to be reconciled according to the transaction indicators.

[0030] Optionally, the transaction indicators of the offset-aligned time sequence payment sequence and the time sequence account sequence are synchronously collected through a preset time window, and a plurality of abnormal sub-time periods are screened from the reconciliation time period to be reconciled according to the transaction indicators, including the following steps:

[0031] The transaction indicators of the time sequence payment sequence and the time sequence account sequence that have completed time stamp alignment are synchronously collected through a preset time window, and the transaction indicators include the transaction total amount and the transaction total frequency of the key payment data and the key account data in each time window;

[0032] For any time window, the comprehensive deviation index of the time sequence payment sequence and the time sequence account sequence in the time window is calculated according to the transaction indicators;

[0033] If the comprehensive deviation index is in a preset index threshold interval, the time window is marked as an abnormal time window;

[0034] The timestamp based on the abnormal time window completes window merging between the abnormal time windows, obtains a plurality of continuous abnormal windows, and determines a plurality of abnormal sub-time periods in the to-be-reconciled time period according to the continuous abnormal windows. Optionally, the method for checking the explicit abnormal orders in the abnormal sub-time period based on the rule engine comprises the following steps:

[0035] The pre-acquired medical payment rules are converted into structured rules, and a rule engine is constructed according to the structured rules;

[0036] The core order fields of all payment orders and receipt orders in the abnormal sub-time period are extracted by using a template matching algorithm, and all the core order fields are integrated into a plurality of core transaction information in sequence with corresponding transaction data sets;

[0037] All the core order information is input into the rule engine in sequence, the core transaction information is checked by the rule engine, and the engine checking result is output;

[0038] The explicit abnormal orders in the abnormal sub-time period are determined according to the engine checking result.

[0039] Optionally, the hidden state inference of the entire transaction data set is completed by using an implicit abnormality identification model, and the implicit abnormal orders in the to-be-reconciled time period are determined according to the hidden state inference result, comprising the following steps:

[0040] Normal transaction data in historical reconciliation records is screened out, and the historical reconciliation records are stored in a hospital information center;

[0041] The normal transaction data is used as a training set, and the implicit abnormality identification model is trained by unsupervised learning until the implicit abnormality identification model outputs a maximum likelihood probability, and the implicit abnormality identification model is constructed based on a hidden Markov model;

[0042] A transaction observation sequence of the entire transaction data set is constructed;

[0043] All the transaction observation sequences are input into the trained implicit abnormality identification model in sequence, and the joint probability of each transaction observation sequence in the implicit abnormality identification model is calculated by using a forward algorithm;

[0044] The transaction observation sequences with a joint probability less than a preset probability threshold are marked as abnormal observation sequences, and the implicit abnormal orders of all the abnormal sub-time periods are determined according to the abnormal observation sequences.

[0045] Optionally, the method further comprises the following steps:

[0046] For any abnormal user, the medical resource consumption of the abnormal user is queried through the hospital information center, and the medical payment amount to be paid by the abnormal user is calculated according to the medical resource consumption;

[0047] The medical payment amount already paid by the abnormal user is calculated according to the payment order and the account arrival order corresponding to the abnormal user;

[0048] If the medical payment amount to be paid is greater than the medical payment amount already paid, a payment prompt information is sent to the abnormal user;

[0049] If the medical payment amount to be paid is less than the medical payment amount already paid, a medical refund strategy is generated according to the pre-acquired fund risk control rule.

[0050] In a second aspect, the present application provides a machine readable storage medium, which 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 the first aspect.

[0051] In a third aspect, the present application provides a system for real-time verification of transaction data based on multiple payment channels, comprising:

[0052] a memory configured to store instructions; and

[0053] a processor configured to call the instructions from the memory and capable of implementing the method for real-time verification of transaction data based on multiple payment channels according to any one of the first aspect when executing the instructions.

[0054] Through the above technical solution, the payment orders of different channels are uniformly stored to the payment database through the aggregation payment platform, so that subsequent reconciliation does not need to be reconciled with each payment platform respectively, greatly reducing the reconciliation workload and improving the reconciliation efficiency. Then, the transaction indicators of the payment orders and the account arrival orders in the to-be-reconciled time period are synchronously collected through the time window, the payment orders and the account arrival orders are batch-verified based on the transaction indicators, a plurality of abnormal sub-time periods are quickly screened out, and the subsequent reconciliation workload is further reduced. Then, the orders in all abnormal sub-time periods are accurately verified by using a rule engine and a hidden Markov model (HMM), the abnormal orders are identified, and the subsequent abnormal processing strategy is formulated according to the medical resource consumption amount of the abnormal user corresponding to the abnormal orders, so as to avoid causing financial losses of the hospital and the patient. In summary, the present application effectively reduces the reconciliation workload and the reconciliation accuracy of the hospital, and improves the financial management efficiency and the patient satisfaction of the hospital.

[0055] Other features and advantages of the present application will be described in detail in the following specific implementation part. BRIEF DESCRIPTION OF DRAWINGS

[0056] Figure 1 A flowchart of a method for real-time verification of transaction data based on multiple payment channels provided by the present application embodiment;

[0057] Figure 2A structural schematic diagram of an online hospital system provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0058] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. It should be understood that the specific embodiments described herein are merely used to explain and illustrate the embodiments of the present application, and should not be used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative effort fall within the scope of protection of the present application.

[0059] It should be noted that if the embodiments of the present application involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are merely used to explain the relative positional relationship, movement condition, etc. between components in a certain specific posture (as shown in the drawings), and if the specific posture changes, the directional indications also change accordingly.

[0060] In addition, if the embodiments of the present application involve descriptions such as “first”, “second”, etc., the descriptions of “first”, “second”, etc. are merely for description purposes, and should not be understood as indicating or implying the relative importance of the indicated technical features or implicitly indicating the number of the indicated technical features. Therefore, the features limited by “first”, “second” can explicitly or implicitly include at least one of the features. In addition, the technical solutions of the various embodiments can be combined with each other, but it must be based on the fact that a person of ordinary skill in the art can implement it, and when the combination of technical solutions contradicts each other or cannot be implemented, it should be considered that the combination of technical solutions does not exist, and is also not within the scope of protection claimed by the present application.

[0061] Figure 1 A flowchart of a method for real-time verification of transaction data based on multiple payment channels according to an embodiment of the present application is shown schematically. As shown in Figure 1 The method for real-time verification of transaction data based on multiple payment channels provided by the embodiments of the present application 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 connection, the hospital information center includes a payment database and a payment arrival database, and the method can include the following steps:

[0062] S101. After receiving a payment request of a target user through the aggregated payment platform, the corresponding payment plug-in is called based on the payment request, and a payment two-dimensional code is generated through the payment plug-in.

[0063] In the embodiment, reference is made to Figure 2The aggregation payment platform comprises a payment module and a refund module, and is communicatively connected to the hospital information center. The aggregation payment platform provides a unified payment interface and a background management system by establishing a unified payment aggregation service and an interface standard. In the payment process, switching between multiple payment applications is not required, and payment can be completed through only one aggregation payment platform. The aggregation payment platform further comprises 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 for controlling the core transaction process safety control such as order creation, payment application, payment confirmation, business application, business confirmation, etc., to realize pre-payment application, verify whether the payment information is incorrect, and confirm the complete record of transaction elements after payment.

[0064] When the target user clicks to pay on the front end (such as the payment interface of the online hospital applet), the aggregation payment platform can immediately receive the payment request of the target user, and call the order API service to create a transaction order. The transaction order contains a unique order number generated by the order API service for the transaction, as a unique identifier for the subsequent payment process, and order basic information, including the payment amount, patient name, department, etc. Next, the identity of the target user is extracted from the payment request or user session, such as user ID, mobile phone number, membership card number, etc. If the target user is not logged in, the identity authentication process may need to be triggered first. According to the identity of the target user, and using the query preset permission rule table such as merchant level, user type, transaction limit, etc., the permission of the target user for the current transaction is verified. If the permission verification of the target user is passed, the corresponding merchant number is matched according to the patient identity, department, service type (such as outpatient, inpatient, medicine), and the preset fund allocation algorithm. Then, according to the merchant number and through the aggregation payment platform, the corresponding configuration information is obtained, and the transaction order is encrypted using the key in the configuration information to obtain an encrypted order. Common encryption methods include AES algorithm, RSA algorithm, etc.

[0065] The aggregation payment platform calls the corresponding payment plug-in, such as the medical insurance electronic voucher interface, according to the payment channel corresponding to the merchant number. Then the aggregation payment platform calls the corresponding payment channel interface through the payment plug-in, and encapsulates the encrypted order into a request message (such as JSON format) conforming to the channel specification, and sends it to the payment server. After receiving the request message, the payment server uses the public key or verification rule of the corresponding payment channel to decrypt and verify the legality of the encrypted order (such as amount consistency, merchant number validity, and signature correctness). If the encrypted order fails the verification (such as the order amount is tampered with), an error code is returned to the front end, prompting the target user to "pay information is abnormal, please re-order". If the encrypted order passes the verification, the order number, order basic information, and payment channel parameters in the encrypted order are encapsulated into a standard format, and the structured data is converted into a black and white matrix pattern through QR code and other standards to obtain a payment two-dimensional code.

[0066] S102. When the target user completes the aggregation payment through the payment two-dimensional code, a payment order is generated, and the payment order is stored in the payment database.

[0067] In this embodiment, after the target user completes the aggregation payment by scanning the payment two-dimensional code, the payment server will send a payment result notification to the callback address of the aggregation payment platform pre-configured in the payment channel, including information such as payment status, order amount, order number, timestamp, and signature value. After receiving the payment result notification, the aggregation payment platform will use the key agreed with the payment channel to sign the callback parameters (such as order number, order amount, timestamp, etc.) in the payment result notification, and compare it with the signature value carried in the payment result notification to prevent data tampering. After verification, a payment order is generated using a fixed payment order template, which includes the payment order number, the original transaction order number, the merchant number, the target user's identity, the payment amount, the patient's name, the department of registration, the timestamp, etc. Then, a "payment order table" is created in the payment database, which contains the above order content, and the payment order number is used as the primary key, and an index is established, such as by merchant number, user ID or payment order number, for quick query. Then the data in the payment order is inserted into the payment order table, the order state of the transaction order is updated to "paid", and the payment order number is associated to form an order link (such as adding a pay_order_id field in the transaction order table), and the operation log (such as operation time, operator / system, IP address) of the payment order storage process is recorded synchronously, which facilitates auditing and fault tracing.

[0068] S103. When the preset reconciliation time node is reached, all payment orders in the payment database within the reconciliation time period are called, and all payment orders within the reconciliation time period are queried through the payment database, and the order reconciliation is completed according to the order reconciliation result, and a number of abnormal users are output.

[0069] In the embodiment, according to the specific time of the time period to be reconciled, all payment orders and all account orders in the time period to be reconciled are respectively batch exported from the payment database and the hospital information center, the payment orders include payment order number, payment amount, patient name, registered department, payment time, etc., and the account orders include account serial number, account amount, account time, associated order number, etc. Then, the key payment data and the key account data in the all payment orders and the all account orders are respectively extracted by using the regular matching algorithm, the key payment data includes payment order number, payment amount and payment time, etc., and the key account data includes account serial number, account amount, account time, etc. The synchronous sampling of all the key payment data and the key account data is completed through a preset time window, and according to the synchronous sampling result, several abnormal sub-time periods in the time period to be reconciled are extracted.

[0070] According to the data matching of the associated order number in the key payment data and the payment order number in the key account data of all abnormal sub-time periods, according to the matching result, the key payment data and the key account data generated in the same transaction process are integrated into a transaction data set. Then, the implicit abnormal order and the explicit abnormal order in each abnormal sub-time period are identified by using the rule engine and the hidden Markov model. Finally, the explicit abnormal order and the implicit abnormal order are integrated to obtain all abnormal orders of the time period to be reconciled, and the target user corresponding to the abnormal order is marked as an abnormal user.

[0071] In one of the embodiments, after receiving the payment request of the target user through the aggregation payment platform, the corresponding payment plug-in is called based on the payment request, and the payment two-dimensional code is gradually generated through the payment plug-in, including the following steps:

[0072] After receiving the payment request of the target user through the aggregation payment platform, the order API service of the aggregation payment platform is called to create a transaction order based on the payment request;

[0073] The identity of the target user is called, and the transaction authority of the target user is checked based on the identity and according to the preset authority rule table;

[0074] If the authority of the target user is checked, the merchant number of the target user is calculated according to the fund allocation algorithm;

[0075] According to the merchant number, the corresponding configuration information is obtained through the aggregation payment platform, and the transaction order is encrypted by using the key in the configuration information to obtain an encrypted order;

[0076] According to the merchant number, the corresponding payment plug-in is called, the encrypted order is sent to the payment server of the aggregation payment platform through the payment plug-in, and the encrypted order is checked by using the payment server;

[0077] If the encrypted order is verified, the payment server generates a payment QR code based on the encrypted order.

[0078] In the embodiment, the aggregation payment platform provides a unified payment interface and a background management system by establishing a unified payment aggregation service and an interface standard. During the payment process, the user does not need to switch between multiple payment applications, but only needs to complete the payment through an aggregation payment platform. The aggregation payment platform further 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 WeChat, Alipay, bank cards, and medical insurance, so as to realize aggregated payment. The order service module is used for controlling the core transaction process safety control such as creating an order, payment application, payment confirmation, business application, business confirmation, etc., realizing pre-payment application, verifying whether the payment information is incorrect, and confirming the complete record of transaction elements after payment.

[0079] When the target user clicks to pay on the front end (such as the payment interface of the online hospital applet), the aggregation payment platform can immediately receive the payment request of the target user and call the order API service to create a transaction order. The transaction order contains a unique order number generated by the order API service for the transaction, such as the patient's visit number, fee details, etc., as the unique identifier for the subsequent payment process, as well as order basic information, including payment amount, patient name, department, etc. Next, the identity of the target user is extracted from the payment request or user session, such as user ID, mobile phone number, membership card number, etc. If the target user is not logged in, the identity authentication process may need to be triggered first. According to the identity of the target user, and by using the query preset permission rule table such as merchant level, user type, transaction limit, etc., it is verified whether the target user has the permission of the current transaction, for example, whether high-frequency transactions are prohibited, whether the single amount limit is exceeded, etc. If the permission verification fails, such as the single transaction limit, an error prompt is returned directly, and the process is terminated. If the permission verification of the target user is passed, the corresponding merchant number is matched according to the patient's identity, the department of treatment, and the type of service (such as outpatient, inpatient, and medicine) by using the preset fund allocation algorithm, for example, the outpatient registration fee is allocated to the "hospital outpatient charge special merchant number", the medicine cost is allocated to the "hospital pharmacy merchant number", and the inspection cost is allocated to the "independent merchant number of the inspection department", realizing the fine settlement of medical expenses according to the department and the type of project, which is convenient for the hospital financial reconciliation and cost accounting.

[0080] Then, the corresponding configuration information such as key, certificate, appid, etc. is obtained according to the merchant number and through the aggregation payment platform, and the key in the configuration information is used to encrypt the transaction order to obtain an encrypted order, so as to ensure the security of the patient privacy information (such as patient medical record, payment amount, etc.) in the transaction order during transmission. Common encryption methods include AES algorithm, RSA algorithm, etc. Taking the AES encryption algorithm as an example, the initial key is first generated into multiple round keys (such as 44 32-bit words generated by AES-128) through a key scheduling algorithm, then the first round key is used to perform an exclusive or operation on the transaction order, and the transaction order after the first round key exclusive or operation is processed through multiple rounds of iteration (byte substitution, row shift, column confusion, round key addition) and final round processing to obtain the final encrypted order.

[0081] The aggregation payment platform calls the corresponding payment plug-in according to the payment channel corresponding to the merchant number, such as medical insurance payment, such as medical insurance electronic voucher interface. The merchant number is the exclusive identity of the hospital in each payment channel (such as UnionPay, medical insurance payment platform, etc.), and the merchant numbers of different channels are different, so the aggregation payment platform can determine which payment channel the current transaction should interact with according to the merchant number. In addition, the interface specification, parameter format and communication protocol of different payment channels are significantly different, such as some payment using APIv3 interface, and UnionPay needs to be connected through UnionPay business gateway, so the corresponding payment plug-in needs to be called according to the payment channel. The core function of the payment plug-in is to encapsulate the API interface of the payment channel, so that the aggregation payment platform can call the channel capabilities (such as generating a payment QR code, verifying the payment status), and realize the secure communication between the aggregation payment platform and the payment channel. Then the aggregation payment platform calls the corresponding payment channel interface through the payment plug-in, and encapsulates the encrypted order into a request message (such as JSON format) conforming to the channel specification, and sends it to the payment server. The essence of the payment server is the core transaction processing system of different payment channels, which is responsible for managing fund flow, verifying transaction legality, and maintaining account data. After receiving the request message, the payment server uses the public key or verification rule of the corresponding payment channel to decrypt and verify the legality of the encrypted order (such as amount consistency, merchant number validity, signature correctness). If the encrypted order fails the verification (such as the order amount is 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 passes the verification, the order number, order basic information, and payment channel parameters in the encrypted order are encapsulated into a standard format through the payment channel, and the structured data is converted into a black and white matrix pattern through QR code and other standards to obtain a payment QR code.

[0082] In one embodiment, all payment orders in the payment database within the period to be reconciled are retrieved, and all bank-in orders in the bank-in database within the period to be reconciled are queried, all payment orders and bank-in orders are combined to complete order reconciliation, and several abnormal users are output according to the order reconciliation result, including the following steps:

[0083] All payment orders in the payment database within the period to be reconciled are retrieved, and all bank-in orders in the hospital information center within the period to be reconciled are queried;

[0084] Based on the regular matching algorithm, the key payment data and key bank-in data in all payment orders and bank-in orders are extracted respectively;

[0085] Synchronous sampling of all key payment data and key bank-in data is completed through a preset time window, and several abnormal sub-periods within the period to be reconciled are extracted according to the synchronous sampling result;

[0086] Data matching of key payment data and key bank-in data in all abnormal sub-periods is completed, and a plurality of transaction data sets are obtained;

[0087] For any abnormal sub-period, the explicit abnormal order in the abnormal sub-period is checked based on the rule engine;

[0088] The hidden state inference of all transaction data sets is completed by using the implicit abnormality recognition model, and the implicit abnormal order in the period to be reconciled is determined according to the hidden state inference result;

[0089] All abnormal orders in the period to be reconciled are determined by combining all explicit abnormal orders and implicit abnormal orders, and the corresponding abnormal users are output according to the abnormal orders.

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

[0091] Next, the synchronization sampling of all key payment data and key account data is completed through a preset time window, and several abnormal sub-time periods in the to-be-reconciled time period are extracted according to the synchronization sampling result. Specifically, the historical reconciliation records are first queried through the hospital information center, and the historical reconciliation records include historical account information, historical payment information, and transaction status. Next, the target reconciliation data is obtained after the historical reconciliation records are preliminarily screened according to the record integrity. The time difference between the payment timestamp and the account timestamp in the target reconciliation data is taken as the account time difference, and then the mean and time difference of all account time differences are calculated. According to the mean and time difference, the outliers in all account time differences are removed, and the mean of all account time differences after removing the outliers is calculated to obtain the time mean, which is taken as the time compensation parameter between the key payment data and the key account data. According to the timestamps in the key payment data and the key account data, the two are sorted according to the timestamps to obtain the time sequence payment sequence and the time sequence account sequence. Next, the time compensation parameter is used to adjust the timestamps of the time sequence payment sequence or the time sequence account sequence, and then the timestamps of the adjusted time sequence payment sequence are aligned with the timestamps of the time sequence account sequence. Next, the transaction indicators of the time sequence payment sequence and the time sequence account sequence that have completed the offset alignment are synchronously collected through a preset time window. The size of the time window can be dynamically adjusted according to the transaction frequency of each sub-time period in the to-be-reconciled time period. For a sub-time period with a high transaction frequency, a smaller time window is used, and vice versa. For a sub-time period with a low transaction frequency, the time window is appropriately expanded to prevent the data volume in a certain time window from being too large. The window sliding step of the time window can be set to 1 / 2 of the window size (such as 30 seconds for a 1-minute window step) to ensure data overlap and avoid missing short-term abnormalities. The transaction indicators include the transaction total amount and the transaction total frequency of the key payment data and the key account data in each time window. For any time window, the transaction total frequency difference and the transaction total amount difference of the time sequence payment sequence and the time sequence account sequence in the time window are first calculated, and then the differences are weighted and fused to obtain a comprehensive deviation index. The time window with a comprehensive deviation index in a preset index threshold interval (which can be (0, 0.7]) is marked as an abnormal time window. After the comprehensive deviation index is calculated, all abnormal windows are checked two by two to check whether there is time overlap or time continuity between the abnormal windows. The abnormal windows with time overlap or time continuity are merged to obtain several continuous abnormal windows, and the several abnormal sub-time periods in the to-be-reconciled time period are determined according to the continuous abnormal windows.

[0092] According to the data matching of the associated order number in the key payment data of the entire abnormal sub-time period and the payment order number in the key account data, in order to reduce the workload of subsequent reconciliation, the associated order number in the account order is stored in the same payment order number as the corresponding payment order, so that the key payment data and the key account data generated in the same transaction process can be directly matched and integrated into a transaction data set.

[0093] Then the explicit abnormal orders and explicit abnormal bills in each abnormal sub-time period are identified. First, the medical payment rules are obtained from multiple sources, such as hospital internal systems, industry standards, etc., and then the medical payment rules are subjected to semantic analysis to extract core elements, including condition items, action items, rule types and constraint conditions. Then the extracted unstructured medical payment rules are converted into structured rules, usually in a SON or XML structure. Specifically, the unstructured medical payment rules are first decomposed, the core elements are extracted, and the unique identifier, rule name, rule detailed description, structured representation of condition expression, definition of trigger action and metadata (such as priority, applicable scenario, validity period) of the medical payment rule are defined. Then the module architecture of the rule engine is constructed, including the parser, rule storage layer, matching engine and execution engine, and management interface. After completing the construction of the rule engine module architecture, an index is established according to the rule condition field (such as "payment amount" and "payment type"). When the core order information is input, the candidate rules are filtered directly through the index. At the same time, the triggering mechanism of the rule engine is defined, and when the core order information is input, the rule matching is triggered actively. After the above steps, the final rule engine is obtained. After the core order information is structured, it is input into the rule engine in turn, and the structured report of each core order information is output by the rule engine. The structured report of the payment order and the account order is integrated to obtain the explicit abnormal order. The explicit abnormalities in the explicit abnormal order mainly include the inconsistency of the payment amount and the account amount, and the inconsistency of the payment object of the same order.

[0094] Then the implicit abnormal orders are identified by the hidden Markov model. First, the normal transaction data is selected from the historical reconciliation records stored in the hospital information center, and then the implicit abnormality identification model is constructed. First, the hidden states of the implicit abnormality identification model are defined, and the number of states is set according to the reconciliation experience. The initial state probability, state transition probability and emission probability of the implicit abnormality identification model are initialized, thereby completing the model construction of the implicit abnormality identification model.

[0095] The training set is input into the implicit anomaly recognition model, and the expectation maximization (EM) algorithm is used to update the model parameters through iteration to maximize the likelihood probability of the observation data of the implicit anomaly recognition model. When the implicit anomaly recognition model outputs the maximum likelihood probability or reaches the preset maximum iteration number, the training is completed. After extracting the transaction features of the entire transaction data set, the transaction features are integrated in chronological order to obtain the transaction observation sequence. The entire transaction observation sequence is 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 sequence with a joint probability less than a preset probability threshold is marked as an abnormal observation sequence. Finally, the payment order and the arrival order corresponding to the abnormal observation sequence are marked as implicit abnormal orders.

[0096] The implicit anomaly identified by the implicit anomaly recognition model is mainly the anomaly that is difficult to identify by the rule engine, for example, the target user repeatedly pays multiple times in a short time, the arrival time is earlier than the payment time in the same transaction process, etc. These anomalies may be caused by the failure of the aggregation payment platform, resulting in errors in the generated payment bill or arrival bill, or may be caused by abnormal behavior of the target user, such as repeated payment, which may be a ticket scalper. These implicit anomalies are easily overlooked by the rule engine, so the hidden Markov model is used for implicit anomaly recognition. Finally, the explicit abnormal order and the implicit abnormal order are integrated to obtain all abnormal orders in the time period to be reconciled, and the target user corresponding to the abnormal order is marked as an abnormal user.

[0097] The following steps are further included after outputting the abnormal user:

[0098] For any abnormal user, collect multi-source transaction information of the abnormal user, and the multi-source transaction information includes user transaction data, payment device data, user behavior data, and user payment logs;

[0099] Complete entity association and sequence alignment of the multi-source transaction information to generate a multi-dimensional abnormal graph;

[0100] Taking the abnormal order node in the multi-dimensional abnormal graph as the starting point, performing bidirectional random walk in the multi-dimensional abnormal graph, and extracting an initial abnormal propagation path in the multi-dimensional abnormal graph according to the bidirectional random walk result;

[0101] Pruning the initial abnormal propagation path by using a graph pruning algorithm to obtain an abnormal propagation subgraph;

[0102] Extracting initial abnormal nodes of the abnormal propagation subgraph, determining the causal relationship between the initial abnormal nodes by using a causal discovery algorithm, and calculating the causal effect strength of the initial abnormal nodes according to the causal relationship extraction result;

[0103] According to the causality effect intensity, a plurality of key abnormal nodes in the initial abnormal nodes are screened out, and payment optimization prompt information is generated based on all the key abnormal nodes.

[0104] Specifically, after all the abnormal users are identified, first, the distributed data collection engine is used to synchronously acquire multi-source transaction information, including acquiring payment orders, payment channel callback records, and medical insurance reimbursement details and other user transaction data through the aggregation payment platform API, collecting user behavior data such as abnormal user operation tracks through the front-end embedded point SDK, extracting system log data (user payment log) such as payment interface call logs from the hospital information center server, and acquiring payment device data such as device fingerprints, network IP, and geographic location through the mobile terminal SDK. In the preprocessing stage, the ETL tool is used to complete the steps of structured data standardization, semi-structured log analysis, unstructured track data vectorization, and missing value processing.

[0105] Then multi-source entity recognition is performed on the above multi-source transaction information. First, unique identifiers (such as user ID, order ID) are directly associated to form the core nodes of the multi-dimensional anomaly graph, for example, each order ID corresponds to an order entity, containing attributes such as amount and payment time. And from the multi-source transaction information, implicit information is mined, such as generating a "large transaction" entity according to the transaction amount threshold (such as ≥500 yuan), or identifying an "abnormal operation" entity based on the interaction duration in the abnormal user operation track. Combined with the context information in the multi-source transaction information, such as the "peak period" entity from 10:00 to 11:30 every day, or the "remote login" entity generated according to the device geographic location. In the entity feature extraction link, in addition to the original attributes, dynamic features (such as device IP change frequency, user historical abnormal rate) also need to be calculated, and the dimension difference is eliminated through normalization processing. After completing the multi-source entity recognition, the multi-source transaction information (such as user behavior data and user payment logs) is parsed, and the association relationship is extracted. For example, from "payment failure due to system timeout", the causal association relationship of "payment failure-caused by- system timeout" is identified. Also, the rule engine can be used to define clear strong association relationships between entities, such as "user-[initiate payment]-order". For the identified entities, such as users, orders, devices, system components, and corresponding association relationships, such as payment, attribution, etc., attribute mapping and standardization are performed, and the data is divided into different types, such as numerical type, such as amount 580.50 yuan, timestamp 16:22:30, enumeration type, such as payment status, divided into pending payment, paid, refunded, text type, such as error message "amount inconsistency", and time type, converted to UTC timestamp, such as 2024-08-05 16:22:30 converted to 1712372550. Through standardization processing, the data formats of different sources are consistent, which is convenient for subsequent analysis. Subsequently, knowledge fusion and alignment are performed, and through entity alignment operation, the same entity in different data sources is associated using user ID, order number, etc., for example, the records of the same user in different transactions are associated. After completing the above steps, the entities and the association relationships between the entities are stored and represented in the graph, using a graph database such as Neo4j to store nodes and relationships, and the node contains basic information and feature vector, such as the user node contains user ID, name, etc. Basic information and behavior feature vector. The weight of the edge is dynamically calculated based on transaction frequency, amount size, etc. through attention mechanism, so that the obtained multi-dimensional anomaly graph can reflect the strength and dynamic changes of the relationship between entities.

[0106] After the construction of the multi-dimensional anomaly graph, the abnormal order node in the multi-dimensional anomaly graph is taken as the starting point, and bidirectional random walk is performed and the abnormal propagation probability is calculated. Bidirectional random walk is to start from the abnormal order node and walk in the past and future time directions at the same time, to explore all possible paths associated with the abnormal order node. In the process of walking, when selecting the next node at each step, the probability is determined according to the weight of the edge. The calculation of the edge weight considers multiple factors, such as time correlation, such as multiplying the transaction edge weight by 1.5 within the last 30 minutes, business correlation, such as multiplying the order edge weight of the same department by 1.2, historical abnormality, such as multiplying the edge weight of the abnormality by 1.8. The calculation of the abnormal propagation probability is based on the transition probability of each step. Starting from the starting point, after passing through each edge, the weight of the edge is multiplied by the probability of the current path to obtain the new abnormal propagation probability. For example, the path is “abnormal order→user→device”, if the edge weight of “abnormal order→user” is 0.9, and the edge weight of “user→device” is 0.8, then the abnormal propagation probability of the path is 0.9×0.8=0.72. By traversing all possible paths (set the maximum walking step number to 5 steps), the initial abnormal propagation path is generated, and the abnormal propagation probability of all possible initial abnormal propagation paths is calculated.

[0107] Then, the graph pruning algorithm is used to delete irrelevant nodes and edges in the initial abnormal propagation path according to the preset rules, such as deleting nodes unrelated to the current abnormal type (payment not arrived), such as other department diagnosis and treatment item nodes, or deleting edges with abnormal propagation probability less than 0.5 to reduce noise interference. Taking the initial abnormal propagation paths “order→user→device” and “order→payment channel→system interface” as examples, check whether the nodes in the initial abnormal propagation path are related to the anomaly, if the initial abnormal propagation path exists “order→user→patient→other order” path, and other orders have no anomaly, then delete this branch. After pruning, the paths with abnormal propagation probability greater than or equal to the preset probability threshold (such as 0.7) are retained to form the abnormal propagation subgraph.

[0108] Next, the initial abnormal nodes of the abnormal propagation subgraph are extracted, such as abnormal orders, abnormal users, abnormal devices, and abnormal payment channels, and then a causal discovery algorithm is used to determine the causal relationship between the initial abnormal nodes in the abnormal propagation subgraph and calculate the causal effect strength. The commonly used causal discovery algorithm is the PC algorithm. Specifically, a variable set is first constructed based on the abnormal propagation nodes, and conditional independence test is performed on each pair of variables in the variable set. The chi-square test can be used to determine whether two variables are independent given other variables. For example, whether "system interface abnormality" and "order abnormality" are independent given "payment channel abnormality". If two variables are independent under a certain condition set, the edge between them is deleted. The causal direction is determined by V-structure (such as A→B←C) and directional rules (such as preventing the formation of a ring). For example, if "system interface abnormality→payment channel abnormality→order abnormality" is found, a causal chain is formed, and the causal relationship between nodes is obtained. Next, the causal effect strength of the initial abnormal nodes is calculated according to the causal relationship extraction result. The causal effect strength is a quantitative indicator for measuring the degree of influence of the cause variable on the result variable in the causal relationship. Its core is to depict the change amplitude of the result variable when the cause variable is intervened (i.e. actively changed). For example, the variable set [order abnormality (Y), user abnormality (X1), device abnormality (X2), payment channel abnormality (X3), system interface abnormality (X4)], and then set the control group and the intervention group: 120 transactions with X4 (system interface timeout), of which 96 (80%) have Y; the control group: find 120 transactions that do not have X4 but have similar characteristics through propensity score matching, of which 24 (20%) have Y, thereby obtaining the causal effect strength of system interface timeout (X4) on the result variable Y: (ACE(X4→Y)=80%-20%=60%). According to the causal effect strength, the key abnormal nodes are screened, such as setting a threshold, and payment optimization prompt information is generated based on the screened key abnormal nodes. In addition, in order to ensure that the key abnormal nodes screened subsequently are more accurate, the degree centrality, betweenness centrality, and abnormal propagation probability of the initial abnormal nodes in the abnormal propagation subgraph when a bidirectional random walk reaches the initial abnormal nodes can also be calculated. For each initial abnormal node, the causal effect strength of the initial abnormal node on other initial abnormal nodes with which it has a causal relationship, the degree centrality, betweenness centrality, and abnormal propagation probability of the initial abnormal node in the abnormal propagation subgraph when a bidirectional random walk reaches the initial abnormal node are weighted and fused to obtain a comprehensive strength indicator. The key abnormal nodes are screened according to the comprehensive strength indicator, i.e. the initial abnormal nodes with a comprehensive strength indicator greater than a preset threshold are regarded as key abnormal nodes. And payment optimization prompt information is generated based on the screened key abnormal nodes. Subsequently, the maintenance personnel of the payment platform will optimize the platform according to the payment optimization prompt information.

[0109] In one embodiment, the synchronization sampling of all key payment data and key account data is completed through a preset time window, and several abnormal sub-time periods in the time period to be reconciled are extracted according to the synchronization sampling results, including the following steps:

[0110] The historical reconciliation records of the hospital information center are called, the account time difference of the aggregation payment platform is calculated according to the historical reconciliation records, and the time compensation parameter between the key payment data and the key account data is determined according to the account time difference;

[0111] The key payment data and the key account data are sorted according to the time stamp to obtain the time sequence payment sequence and the time sequence account sequence;

[0112] The time stamp offset alignment of all time sequence payment sequences and time sequence account sequences is completed according to the time compensation parameter;

[0113] The transaction indicators of the offset-aligned time sequence payment sequences and time sequence account sequences are synchronously collected through a preset time window, and several abnormal sub-time periods are selected from the time period to be reconciled according to the transaction indicators.

[0114] In the present embodiment, the hospital information center corresponds to a hospital information system (HIS system), which refers to a comprehensive information system for realizing hospital management informatization and digitization by using computer technology, network communication technology and database management technology to collect, store, process, analyze, transmit and share various business data of the hospital. It is the core infrastructure of modern hospital operation, covering the whole process of medical services, administrative management and financial accounting. The hospital information center stores clinical diagnosis and treatment information such as examination records, medication records, surgery arrangements and disease records of each patient, drug and consumable information such as drug procurement, warehousing, inventory information, medical consumable requisition and use registration, and financial reconciliation information such as order receipt and reconciliation records. Therefore, historical reconciliation records can be directly queried through the hospital information center, which contain historical receipt information, historical payment information and transaction status. Then, when calculating the account time difference using the historical reconciliation records, the historical reconciliation records also need to be filtered to obtain target reconciliation records for calculating the account time difference. The target reconciliation records can be filtered to be close to the current reconciliation time node and cover the complete reconciliation period. In addition, it is also necessary to ensure the field integrity of the filtered target reconciliation records, that is, to contain complete transaction serial numbers, payment timestamps, receipt timestamps and transaction statuses. This is to ensure that the transaction serial number can associate historical payment information and historical receipt information when calculating the time compensation parameter subsequently, and to ensure that the target reconciliation records do not appear to be misplaced, such as A transaction historical payment information being mistakenly matched to B transaction historical receipt information. The payment timestamp and the receipt timestamp are the basic data for calculating the account time difference, which will only result in the inability to calculate the account delay, i.e. the account 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 account time difference.

[0115] After filtering out the target reconciliation records that meet the requirements, the time difference between the payment timestamp and the receipt timestamp in the target reconciliation data is taken as the account time difference, and then the mean and the time difference of all account time differences are calculated. According to the mean and the time difference, the abnormal values in all account time differences are removed, for example, the account time difference greater than the mean + 2x standard deviation is removed as an abnormal value. By this method, abnormal values caused by network fluctuations, system failures and other special events are removed, ensuring that the calculated account time difference can reflect the account delay in the normal transaction process. Then, the mean of all account time differences after removing the abnormal values is calculated to obtain the time mean, which is taken as the time compensation parameter between the key payment data and the key receipt data.

[0116] Then, according to the time stamps in the key payment data and the key account data, the two are sorted according to the time stamps to obtain the time sequence payment sequence and the time sequence account sequence. Then, the time stamps of the time sequence payment sequence or the time sequence account sequence are adjusted using the time compensation parameter, for example, the time stamps of the time sequence payment sequence are adjusted using the time compensation parameter, and the time stamps of the time sequence payment sequence are directly added to the time compensation parameter to obtain the adjusted time stamps. Then, the adjusted time stamps of the time sequence payment sequence and the time stamps of the time sequence account sequence are timestamped. The time compensation parameter plays a calibration role in the timestamp alignment process. Since the time stamps of the key account data are easily affected by fixed factors such as payment channels, bank clearing processes, and random factors such as network delays and system loads, the time stamps of the key payment data and the key account data generated in the same transaction process will be offset, which is specifically manifested as the time stamps of the key account data being later than the time stamps of the key payment data. Based on the above reasons, before aligning the time stamps of the two, the time offset rule of the key payment data and the key account data needs to be quantified to calculate the time compensation parameter, and the originally asynchronous time sequence data is adjusted to a sequence with a unified time reference.

[0117] Then, the transaction indicators of the time sequence payment sequence and the time sequence account sequence that have completed offset alignment are synchronously collected using a preset time window. The size of the time window can be dynamically adjusted according to the transaction frequency of each sub-time period in the period to be reconciled. For sub-time periods with higher transaction frequency, a smaller time window is used, and vice versa. For sub-time periods with lower transaction frequency, the time window is appropriately expanded to prevent the data volume in a certain time window from being too large. The window sliding step of the time window can be set to 1 / 2 of the window size (such as 30 seconds for a 1-minute window step) to ensure data overlap and avoid missing short-term abnormalities.

[0118] The transaction indicators include the total transaction amount and the total transaction frequency of the key payment data and the key account data in each time window, the total transaction amount includes the total payment amount and the total account amount, and the total transaction frequency includes the total payment frequency and the total account frequency. For any time window, first, the total transaction frequency difference and the total transaction amount difference of the time series payment sequence and the time series account sequence in the time window are calculated, then the differences of the two are weighted and fused to obtain a comprehensive deviation index. The time window in which the comprehensive deviation index is in a preset index threshold interval (which can be (0, 0.7]) is marked as an abnormal time window. In addition, when the comprehensive deviation index is greater than the upper limit value (such as 0.7) of the preset index threshold interval, it indicates that there is a large transaction that has not been accounted for or a collective transaction that has not been accounted for, etc. At this time, the account reconciliation warning is triggered, and the alarm information is immediately sent to the aggregation account platform, reminding the maintenance personnel of the aggregation payment platform to perform system troubleshooting, such as checking the payment interface log, the transaction records of the account database and the payment database, and confirming whether there is a system error (such as SQL timeout, interface return failure but front end display success). At the same time, the abnormal time window is traced back, specifically, the key payment data and the key account data in the time window are checked one by one, the bank flow of the related user and the medical insurance repayment single are checked to confirm the difference between the actual account amount and the system record, and various paper bills of the related user are checked to check whether there is a manual input error (such as an extra zero). In the shortest time, the abnormal source is found out to prevent major losses in the hospital.

[0119] After the calculation of the comprehensive deviation index is completed, the two-by-two verification of all abnormal windows is performed to check whether there is time overlap or time continuity between the abnormal windows. The abnormal windows with time overlap or time continuity are merged to obtain a plurality of continuous abnormal windows, and a plurality of abnormal sub-time periods in the to-be-reconciled time period are determined according to the continuous abnormal windows. The originally scattered abnormal time windows are merged into continuous abnormal windows, and the originally isolated abnormal data are merged into continuous abnormal data, which can effectively associate the abnormalities between different abnormal time windows. For example, two abnormal time windows may be “payment anomaly” and “account anomaly”, respectively. After merging, the complete logic of “delayed account” can be found through the cross-window data association in the continuous time period, rather than isolated single-point anomaly.

[0120] In one embodiment, the transaction indicators of the time series payment sequence and the time series account sequence that complete the offset alignment are synchronously collected through a preset time window, and a plurality of abnormal sub-time periods are selected from the to-be-reconciled time period according to the transaction indicators, including the following steps:

[0121] The transaction indicators of the time-stamped payment sequence and the time-stamped account sequence are synchronously collected in preset time windows to complete time alignment, and the transaction indicators include transaction total amount and transaction total frequency of the key payment data and the key account data in each time window;

[0122] For any time window, a comprehensive deviation index of the time-stamped payment sequence and the time-stamped account sequence in the time window is calculated according to the transaction indicators;

[0123] If the comprehensive deviation index is in a preset index threshold range, the time window is marked as an abnormal time window;

[0124] Based on the time stamps of the abnormal time windows, window merging is performed between the abnormal time windows to obtain a plurality of continuous abnormal windows, and a plurality of abnormal sub-time periods in the time period to be reconciled are determined according to the continuous abnormal windows. In this embodiment, the transaction indicators of the time-stamped payment sequence and the time-stamped account sequence that have completed offset alignment are synchronously collected by using preset time windows. The size of the time window can be dynamically adjusted according to the transaction frequency of each sub-time period in the time period to be reconciled. For a sub-time period with a higher transaction frequency, a smaller time window is used, and vice versa. For a sub-time period with a lower transaction frequency, the time window is appropriately enlarged to prevent the data volume in a certain time window from being too large. For example, when the transaction frequency is greater than or equal to 120 transactions per 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 per minute, the time window is ± 60 seconds. The window sliding step of the time window can be set to 1 / 2 of the window size (such as 30 seconds for a 1-minute window step), to ensure data overlap and avoid missing short-term abnormalities.

[0125] The transaction indicators include transaction total amount and transaction total frequency of the key payment data and the key account data in each time window, the transaction total amount includes payment total amount and account total amount, and the transaction total frequency includes payment total frequency and account total frequency. For any time window, the transaction total frequency difference and the transaction total amount difference of the time-stamped payment sequence and the time-stamped account sequence in the time window are calculated first, then the differences are weighted and fused. Specifically, the dimension difference between the transaction total frequency difference and the transaction total amount difference is eliminated first, which can be eliminated by using Z-Score standardization and extreme value standardization, then weights are assigned to the two for weighted fusion to obtain a comprehensive deviation index. For example, the transaction total frequency difference is 2 and the transaction total amount difference is 165.7 yuan, then the dimension difference between the two is eliminated by using Z-Score standardization (assuming that the historical frequency standard deviation is 10 and the historical amount standard deviation is 500), the transaction total frequency difference is 0.2 and the transaction total amount difference is 0.3314, then the transaction total frequency difference weight is set to 0.4 and the transaction total amount difference weight is set to 0.6, and the calculated comprehensive deviation index is 0.27884.

[0126] The time window in which the comprehensive deviation index is in the preset index threshold interval (which can be (0, 0.7]) is marked as an abnormal time window. When the comprehensive deviation index is greater than the upper limit value (such as 0.7) of the preset index threshold interval, it indicates that a large amount of transactions are not credited or a group of transactions are not credited, and at this time, an account reconciliation warning is triggered, and an alarm information is sent to the aggregation payment platform to remind the maintenance personnel of the aggregation payment platform to troubleshoot the system, such as checking the payment interface log, the transaction records of the account database and the payment database, and confirming whether there is a system error (such as SQL timeout, interface return failure but front end display success). At the same time, the abnormal time window is traced back, specifically, the key account data and key payment data in the time window are checked one by one, the bank flow of the related user and the medical insurance repayment single are checked, the difference between the actual account amount and the system record is confirmed, and various paper bills of the related user are checked to check whether there is a manual input error (such as an extra zero in the amount). In the shortest time, the abnormal source is found out to prevent the hospital from incurring significant losses.

[0127] After the calculation of the comprehensive deviation index is completed, all abnormal windows are checked two by two to check whether there is time overlap or time continuity between each abnormal window, the abnormal windows with time overlap or time continuity are merged to obtain a plurality of continuous abnormal windows, and a plurality of abnormal sub-time periods in the to-be-reconciled time period are determined according to the continuous abnormal windows. For example, the abnormal time windows are [9:00-9:10], [9:05-9:15], [9:30-9:40] and [9:40-9:50], wherein [9:00-9:10] and [9:05-9:15] have time overlap, and therefore can be merged into a continuous abnormal window [9:00-9:15], [9:30-9:40] and [9:40-9:50] have time continuity, and therefore can be merged into a continuous abnormal window [9:30-9:50], and [9:00-9:15] and [9:30-9:50] are taken as abnormal sub-time periods respectively. Merging the originally dispersed 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 can be “payment abnormality” and “accounting abnormality”, and after merging, the complete logic of “delayed accounting” can be found through the cross-window data association in the continuous time period, rather than isolated single-point abnormality.

[0128] In one embodiment, the explicit abnormal order in the abnormal sub-time period is checked based on a rule engine, including the following steps:

[0129] The pre-obtained medical payment rules are converted into structured rules, and a rule engine is constructed according to the structured rules;

[0130] The core order fields of all payment orders and receipt orders in the abnormal sub-period are extracted by using a template matching algorithm, and all the core order fields are sequentially integrated with the corresponding transaction data set to form multiple core transaction information;

[0131] All core order information is sequentially input into the rule engine, the core transaction information is verified by the rule engine, and the engine verification result is output;

[0132] According to the engine verification result, the explicit abnormal order in the abnormal sub-period is determined.

[0133] In this embodiment, first, medical payment rules are obtained from multiple sources, such as hospital internal systems, industry standards, etc., and then semantic analysis is performed on the medical payment rules to extract core elements, including condition items: prerequisites for triggering rules, such as “payment amount > 5000 yuan” “payment method is medical insurance pooling” “order time is on non-working days”; action items: processing logic after rule triggering, such as “marked for review” “reject reconciliation” “generate abnormal warning”; rule type: distinguish the priority and application scenario of the rule, such as “mandatory rule” (such as amount consistency verification), “warning rule” (such as high-frequency small-amount transaction); constraint condition: effective range of the rule, such as “only applicable to outpatient payment” “valid until December 2026”. Then the extracted unstructured medical payment rules are converted into structured rules, usually in SON or XML structure. Specifically, first, the unstructured medical payment rules are disassembled to extract their core elements, and the unique identifier, rule name, rule detailed description, structured representation of condition expression, definition of triggering action, and metadata (such as priority, application scenario, validity period) of the medical payment rule are defined. For example, the medical payment rule is: when the hospital deposit payment amount exceeds 10000 yuan, or the payment method is credit card and the payment time is between 22:00-6:00, a risk warning needs to be generated and submitted for financial review. After disassembly, the conditions are obtained: condition 1: payment amount > 10000 yuan; condition 2: payment method = credit card; condition 3: payment time is between 22:00-6:00; logical relationship: (condition 1) OR (condition 2 AND condition 3); action: generate risk warning + submit financial review; constraint: applicable to hospital deposit payment scenario. Then the medical payment rules that have completed disassembly and structure definition are subjected to consistency verification, including syntax verification: ensure that the JSON / XML format is correct and the fields are not missing; logic verification: check if the condition expression has contradictions, such as “amount > 5000 and amount < 3000”; coverage verification: avoid gaps between rules, such as no rule covers “amount = 5000 yuan” or repeated coverage, such as two rules define different actions for the same condition.

[0134] The module architecture of the rule engine is constructed, including a parser: converting structured rules into internal data structures processable by the engine, such as rule trees, condition linked lists. A rule storage layer: using an index structure (such as a hash table, a prefix tree) to store rules, supporting fast retrieval and update; a matching engine: based on the input core transaction information, efficiently matching applicable rules; an execution engine: executing corresponding actions according to the matching results, and recording execution logs; a management interface: providing rule adding, deleting, modifying, querying, version control, testing functions. After the construction of the rule engine module architecture, indexes are established according to rule condition fields (such as "payment amount" "payment type"), and when the core order information is input, the candidate rules are directly filtered through the indexes. At the same time, the trigger mechanism of the rule engine is defined, and when the core order information is input, the rule matching is triggered actively. After the above steps, the final rule engine is obtained.

[0135] Since the payment order and the arrival order are both structured, for the payment order and the arrival order, the fields are directly defined in combination with the reconciliation rules (such as amount consistency), such as payment status (success / failure), payment channel (credit card / medical insurance, etc.), payment type (self-pay / plan) and payment object (drug / examination), etc. According to the defined fields, the core order fields in the payment order and the arrival order are directly identified, and all core order fields of the same target user are sequentially integrated with the corresponding transaction data set to form multiple core transaction information. Then the core transaction information is sequentially input into the rule engine, and the rule engine loads the preset structured rules (such as a rule set in JSON structure) when it starts. For each core transaction information, the rule engine traverses all rules in order of priority, and when the core transaction information meets the abnormal conditions of a rule, the rule engine marks the corresponding exception type (such as "amount_mismatch" "unilateral_account") in the result and records the exception details (such as specific field values, rule number violated, check time, etc.). If multiple rules are met at the same time, the result will summarize all matched exception types. The filtered core transaction information with exceptions is summarized by time period and exception type to generate a structured report (such as a list containing order ID, exception type, rule number, field details), and the generated structured report is stored in the exception transaction database for subsequent traceability and statistical analysis, and the payment order and the arrival order corresponding to the structured report are integrated to obtain the explicit abnormal order. The explicit abnormalities in the explicit abnormal order mainly include inconsistent payment amount and arrival amount, inconsistent payment objects of the same order, and other more obvious abnormalities.

[0136] In one embodiment, the hidden state inference of the entire transaction data set is completed by using the implicit abnormality identification model, and the implicit abnormal order of the to-be-reconciled time period is determined according to the hidden state inference result, including the following steps:

[0137] The normal transaction data is screened out from the historical reconciliation records stored in the hospital information center;

[0138] The normal transaction data is taken as a training set, and an implicit anomaly recognition model is trained by using unsupervised learning until the implicit anomaly recognition model outputs a maximum likelihood probability, and the implicit anomaly recognition model is constructed based on a hidden Markov model;

[0139] The transaction observation sequences of the entire transaction data set are constructed;

[0140] The entire 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 by using a forward algorithm;

[0141] The transaction observation sequences with a joint probability less than a preset probability threshold are marked as abnormal observation sequences, and the implicit anomaly orders in the entire abnormal sub-time period are determined according to the abnormal observation sequences.

[0142] In the embodiment, the normal transaction data is screened out from the historical reconciliation records stored in the hospital information center. The normal transaction data refers to historical core transaction information that is not marked as abnormal by the rule engine and the implicit anomaly recognition model and has a successful historical reconciliation result. The implicit anomaly recognition model is constructed based on a hidden Markov model (HMM). The hidden Markov model (HMM) is a probability-based time sequence model, and its core idea is to infer the hidden state sequence (such as phonemes corresponding to speech signals, word types of text, etc.) behind the observed data sequence (such as speech signals, text, etc.). The historical core transaction information is subjected to historical observation feature extraction. The historical observation features include numerical features: payment amount, time difference between arrival time and payment time, transaction frequency, time sequence features: transaction time period, classification features: payment channel (one-hot encoding), business type (outpatient payment / hospital deposit, etc.), and the numerical features are subjected to standardization processing to ensure the convergence stability of the HMM model. The extracted historical observation features are integrated into a feature sequence as a training set of the HMM model.

[0143] Then the hidden abnormality recognition model is constructed. First, the hidden state of the hidden abnormality recognition model is defined, which represents the hidden mode category of the transaction. According to the account experience, the state number N (such as N = 3) is set, for example, S1: normal high-frequency small-amount transaction (such as outpatient registration), S2: normal large-amount low-frequency transaction (such as hospital deposit), S3: normal periodic transaction (such as daily clearing period of medical insurance). The transaction observation sequence is defined, which is the feature vector of the transaction data set, for example, [amount standardized value, frequency standardized value, payment channel code, transaction period code]. The parameter initialization of the hidden abnormality recognition model is performed, and the initial state probability, state transition probability and emission probability of the hidden abnormality recognition model are initialized, so as to complete the model construction of the hidden abnormality recognition model.

[0144] The training set is input into the hidden abnormality recognition model, and the expectation maximization (EM) algorithm is used to update the model parameters iteratively, so that the likelihood probability of the observation data of the hidden abnormality recognition model is maximized. The expectation maximization (EM) algorithm is a class of optimization algorithms that iteratively maximize the likelihood estimate. It optimizes the model parameters by alternating the expectation step (E-step) and the maximization step (M-step). The expectation step is to calculate the expected value of the conditional probability distribution of each data point with respect to the hidden variable given the current model parameters. This step "expects" the value that the hidden variable should take if the model parameters are known. Formally, this step is to calculate the expected value of the log-likelihood function of the complete data (considering the likelihood of the hidden variable). The maximization step (M-step) is to re-estimate the model parameters using the expected value obtained in the E-step as the weight to maximize this weighted complete data log-likelihood function. When the hidden abnormality recognition model outputs the maximum likelihood probability, or reaches the preset maximum iteration number, the training is completed.

[0145] After extracting the transaction features of the entire transaction dataset, the transaction features are integrated in chronological order to obtain the transaction observation sequence. The transaction features include the amount standardized value, the frequency standardized value, the payment channel code, the transaction period code, etc. The amount standardized value refers to the value obtained by standardizing the difference between the payment amount and the total transaction amount. The frequency standardized value refers to the value obtained by standardizing the difference between the total transaction frequency. The payment channel code refers to the code of the payment channel selected by the target user when paying. The transaction period code refers to the code of the difference between the payment time and the arrival time. The entire transaction observation sequence is 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 forward algorithm is a dynamic programming algorithm mainly used to calculate the probability of a given observation sequence in a hidden Markov model. Specifically, the forward algorithm calculates the total probability of the transaction observation sequence, i.e., the joint probability of all possible hidden state sequences. The transaction observation sequence with a joint probability less than a preset probability threshold is marked as an abnormal observation sequence. The probability threshold can be determined according to the joint probability distribution of historical normal transaction data, such as taking the mean-3 times standard deviation of the joint probability as the probability threshold. Finally, the payment order and the arrival order corresponding to the abnormal observation sequence are marked as implicit abnormal orders.

[0146] The implicit anomaly identified by the implicit anomaly recognition model is mainly the anomaly that is difficult to identify by the rule engine, such as the target user repeatedly paying multiple times in a short time, the arrival time being earlier than the payment time in the same transaction process, etc. These anomalies may be caused by the failure of the aggregation payment platform, resulting in errors in the generated payment bill or arrival bill, or may be caused by the abnormal behavior of the target user, such as repeatedly paying multiple times, which may be a ticket scalper. These implicit anomalies are easily overlooked by the rule engine, so the hidden Markov model is used for implicit anomaly recognition.

[0147] In one embodiment, the method further comprises the following steps:

[0148] For any abnormal user, the medical resource consumption of the abnormal user is queried through the hospital information center, and the medical payment amount to be paid of the abnormal user is calculated according to the medical resource consumption;

[0149] The medical payment amount paid of the abnormal user is calculated according to the arrival order and the payment order corresponding to the abnormal user;

[0150] If the medical payment amount to be paid is greater than the medical payment amount paid, a payment prompt information is sent to the abnormal user;

[0151] If the medical payment amount to be paid is less than the medical payment amount paid, a medical refund strategy is generated according to the pre-acquired fund risk control rules.

[0152] In the embodiment, the medical resource consumption of each abnormal user is queried by the hospital information center, the medical resource consumption includes examination items (such as CT, blood routine), drug taking, treatment operations (such as surgery, infusion), etc., the current fee required to be paid by the abnormal user, i.e. the medical fee to be paid, is calculated according to the hospital fee rules. Then the medical fee paid by the abnormal user, i.e. the fee already paid by the target user, is calculated according to the corresponding payment order and payment order of the abnormal user. If the medical fee to be paid is greater than the medical fee paid, it means that the abnormal user has not paid part of the fee, so the payment prompt information is sent to the target user through the patient end of the online hospital system. In addition, if the target patient has objections to the payment prompt information, the patient can send a review application to the online hospital system through the patient end, for example, there may be a situation that the patient completes payment on the aggregation payment platform, but the hospital information center fails to receive the payment information in time, resulting in unilateral account. If the medical fee to be paid is less than the medical fee paid, it means that the target user may have made a repeated payment, so a medical refund strategy needs to be generated and medical refund is performed according to the medical refund strategy. The specific generation method of the medical refund strategy includes: first, obtaining the fund risk control rules of the hospital, the fund risk control rules include daily refund amount, single refund amount and refund channel, etc. First, all target users that need to perform the refund process are integrated, the refund amount of each target user is calculated respectively, and the total refund amount is calculated. If the total refund amount is less than or equal to the daily refund amount, and the refund amount of each target user is less than or equal to the single refund amount, the refund process is performed, and the payment channel of each target user is refunded according to the original route. If there is a total refund amount less than or equal to the daily refund amount, but there is a target user whose refund amount is greater than the single refund amount, the refund amount of the target user needs to be approved, the identity of the target user is confirmed, the refund amount is recalculated, etc. If the approval is passed, the refund amount of the target user is split according to the single refund amount. If the total refund amount is greater than or equal to the daily refund amount, the payment time of each target user is performed in turn, when the daily refund amount is reached, the remaining part continues to perform the refund process the next day, until the refund process of all target users is completed.

[0153] The application also provides a machine-readable storage medium, which stores instructions for causing a machine to execute the method of real-time verification of transaction data based on multiple payment channels according to any one of the above.

[0154] The application also provides a system for real-time verification of transaction data based on multiple payment channels, comprising:

[0155] a memory configured to store instructions; and

[0156] A processor configured to call instructions from the memory and implement the method of real-time verification of transaction data based on multiple payment channels according to any one of the above when executing the instructions.

[0157] The processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), programmable logic devices (PLD), or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. The present application is not limited in this respect.

[0158] The memory can be an internal storage unit of the computer device, for example, a hard disk or a memory of the computer device, or an external storage device of the computer device, for example, a plug-in hard disk, a smart memory card (SMC), a secure digital card (SD), a flash memory card (FC), etc. provided with the computer device, or a combination of the internal storage unit and the external storage device of the computer device. The memory is used to store computer programs and other programs and data required by the computer device, and can also be used to temporarily store data that has been output or will be output. The present application is not limited in this respect.

[0159] The present application also provides a machine readable storage medium having instructions stored thereon for causing a machine to perform the method of real-time verification of transaction data based on multiple payment channels described above.

[0160] Those skilled in the art should understand that embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can be in the form of a completely hardware embodiment, a completely software embodiment or an embodiment combining software and hardware aspects. Moreover, the present application can be in the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.

[0161] The present application is described with reference to flowcharts and / or block diagrams of the method, device (system), computer program product according to embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams can be implemented by computer program instructions, and the combination of flows and / or blocks in the flowcharts and / or block diagrams. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing devices to produce a machine, so that the instructions executed by the computer or other programmable data processing devices produce a device that implements the functions described in the flowcharts and / or block diagrams. Figure 1one or more processes and / or blocks Figure 1 an apparatus with the functionality to achieve the specified function of a block or blocks.

[0162] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 one or more processes and / or blocks Figure 1 an apparatus with the functionality to achieve the specified function of a block or blocks.

[0163] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 one or more processes and / or blocks Figure 1 an apparatus with the functionality to achieve the specified function of a block or blocks.

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

[0165] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) about which the processor can execute instructions. The memory can also include non-volatile memory, such as read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), or flash memory, for example. Memory is an example of computer readable media.

[0166] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), electrically programmable read only memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0167] It should also be noted that the terms "comprising", "comprises" or other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0168] The above embodiments are only used to illustrate the present application, but not to limit it. Instead of the above, various modifications and changes can be made to the application by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the application shall fall into the scope of the claims of the application.

Claims

1. A method for real-time verification of transaction data based on multiple payment channels, characterized in that, The method is applied to an online hospital system, the online hospital system comprising an aggregated payment platform and a hospital information center, the aggregated payment platform and the hospital information center being communicatively connected, the hospital information center comprising a payment database and a payment receipt database, and the method comprising the following steps: After receiving a payment request of a target user through the aggregated payment platform, a corresponding payment plug-in is called based on the payment request, and a payment two-dimensional code is generated through the payment plug-in; After the target user completes the aggregated payment through the payment two-dimensional code, a payment order is generated, and the payment order is stored in the payment database; When a preset reconciliation time node is reached, all payment orders in a to-be-reconciled time period in the payment database are called, and all payment receipt orders in the to-be-reconciled time period are queried through the hospital information center; Based on a regular matching algorithm, key payment data and key payment receipt data in all payment orders and payment receipt orders are extracted respectively; Synchronous sampling of all key payment data and key payment receipt data is completed through a preset time window, and a plurality of abnormal sub-time periods in the to-be-reconciled time period are extracted according to a synchronous sampling result; Data matching of key payment data and key payment receipt data in all abnormal sub-time periods is completed, and a plurality of transaction data sets are obtained; For any abnormal sub-time period, an explicit abnormal order in the abnormal sub-time period is checked based on a rule engine; Hidden state inference of all transaction data sets is completed by using an implicit abnormality identification model, and an implicit abnormal order of the to-be-reconciled time period is determined according to a hidden state inference result; All abnormal orders of the to-be-reconciled time period are determined in combination with all explicit abnormal orders and implicit abnormal orders, and a corresponding abnormal user is output according to the abnormal order.

2. The method of claim 1, wherein, After receiving a payment request of a target user through the aggregated payment platform, a corresponding payment plug-in is called based on the payment request, and a payment two-dimensional code is generated through the payment plug-in, comprising the following steps: After receiving a payment request of a target user through the aggregated payment platform, a transaction order is created based on the payment request by calling an order API service of the aggregated payment platform; The identity of the target user is called, and the transaction authority of the target user is checked based on the identity and according to a preset permission rule table; If the authority of the target user is checked, the merchant number of the target user is calculated according to a fund allocation algorithm; According to the merchant number, corresponding configuration information is obtained through the aggregated payment platform, and the transaction order is encrypted by using the key in the configuration information to obtain an encrypted order; The corresponding payment plug-in is called according to the merchant number, the encrypted order is sent to the payment server of the aggregated payment platform through the payment plug-in, and the encrypted order is checked by using the payment server; If the encrypted order is checked, a payment two-dimensional code is generated based on the encrypted order through the payment server.

3. The method of claim 1, wherein, Synchronous sampling of all key payment data and key payment receipt data is completed through a preset time window, and a plurality of abnormal sub-time periods in the to-be-reconciled time period are extracted according to a synchronous sampling result, comprising the following steps: The historical reconciliation records of the hospital information center are called, the payment time difference of the aggregated payment platform is calculated according to the historical reconciliation records, and the time compensation parameter between the key payment data and the key payment receipt data is determined according to the payment time difference; Sort the key payment data and the key account data according to timestamps to obtain a time-series payment sequence and a time-series account sequence; According to the time compensation parameter, complete timestamp offset alignment of the time-series payment sequence and the time-series account sequence; Synchronously collect transaction indexes of the time-series payment sequence and the time-series account sequence that have completed offset alignment through a preset time window, and according to the transaction indexes, screen a plurality of abnormal sub-time periods from the time period to be reconciled.

4. The method of claim 3, wherein, The step of synchronously collecting transaction indexes of the time-series payment sequence and the time-series account sequence that have completed offset alignment through a preset time window, and according to the transaction indexes, screening a plurality of abnormal sub-time periods from the time period to be reconciled includes the following steps: Synchronously collect transaction indexes of the time-series payment sequence and the time-series account sequence that have completed timestamp alignment through a preset time window, and the transaction indexes include transaction total amount and transaction total frequency of the key payment data and the key account data in each time window; For any time window, according to the transaction indexes, calculate a comprehensive deviation index of the time-series payment sequence and the time-series account sequence in the time window; If the comprehensive deviation index is in a preset index threshold interval, mark the time window as an abnormal time window; Based on the timestamps of the abnormal time windows, complete window merging between the abnormal time windows to obtain a plurality of continuous abnormal windows, and according to the continuous abnormal windows, determine a plurality of abnormal sub-time periods in the time period to be reconciled.

5. The method of claim 1, wherein, The step of verifying explicit abnormal orders in the abnormal sub-time period based on the rule engine includes the following steps: Convert the pre-acquired medical payment rules into structured rules, and construct a rule engine according to the structured rules; Extract core order fields of all payment orders and account orders in the abnormal sub-time period by using a template matching algorithm, and sequentially integrate all the core order fields and corresponding transaction data sets into a plurality of core transaction information; Input all the core transaction information into the rule engine in sequence, verify the core transaction information by the rule engine, and output engine verification results; According to the engine verification results, determine the explicit abnormal orders in the abnormal sub-time period.

6. The method of claim 1, wherein, The step of completing hidden state inference of all transaction data sets by using an implicit abnormality identification model, and determining implicit abnormal orders of the time period to be reconciled according to the hidden state inference results includes the following steps: Screen normal transaction data in historical reconciliation records, and the historical reconciliation records are stored in a hospital information center; Use the normal transaction data as a training set, and train the implicit abnormality identification model by unsupervised learning until the implicit abnormality identification model outputs a maximum likelihood probability, and the implicit abnormality identification model is constructed based on a hidden Markov model; Construct transaction observation sequences of all transaction data sets; Input all the transaction observation sequences into the trained implicit abnormality identification model in sequence, and calculate joint probabilities of each transaction observation sequence in the implicit abnormality identification model by using a forward algorithm; Mark transaction observation sequences with joint probabilities less than a preset probability threshold as abnormal observation sequences, and according to the abnormal observation sequences, determine implicit abnormal orders of all abnormal sub-time periods.

7. The method of claim 1, wherein, The method further includes the following steps: For any abnormal user, the medical resource consumption of the abnormal user is inquired through a hospital information center, and a medical payment amount to be paid of the abnormal user is calculated according to the medical resource consumption; The medical payment amount paid of the abnormal user is calculated according to the payment order and the payment order corresponding to the abnormal user; If the medical payment amount to be paid is greater than the medical payment amount paid, a payment prompt information is sent to the abnormal user; If the medical payment amount to be paid is less than the medical payment amount paid, a medical refund strategy is generated according to the pre-acquired fund risk control rule.

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

9. A multi-payment channel based transaction data real-time verification system, characterized in that, Comprise: a memory configured to store instructions; and a processor configured to call the instructions from the memory and capable of implementing the method for real-time verification of transaction data based on multiple payment channels according to any one of claims 1 to 7 when executing the instructions.

Images