Payment security method and device based on dual-system auditing

Abstract

The invention provides a payment security method and device based on a dual-system auditing mode, and relates to the technical field of finance, and the method comprises the steps: an upstream system calls a payment service system to initiate a payment instruction according to a payment service demand; a service logic processing module in the payment service system verifies the payment instruction and executes payment service processing operation according to set code logic; the payment service system calls an accounting system to finish accounting according to the processing logic; the verification system carries out rationality verification on the processing result of the business logic processing module, and if the verification is not passed, the payment instruction is intercepted; if the verification is passed, the payment service system sends an accounting instruction to an accounting system, and sends a successfully processed payment message to a payment channel at the same time; and the payment channel receives the payment message to complete a safe and reliable typical payment process. According to the invention, an unbreakable firewall is built for the payment service system, and the stability of the payment service system is obviously enhanced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of financial technology, in particular to a payment security method and device based on a dual-system auditing system. BACKGROUND

[0002] At present, the payment business systems of most domestic banks have realized 7x24 hours uninterrupted service, and the public's demand for payment business settlement speed is increasing year by year. Under this background, more than 60% of the payment business of ordinary banks can be completed within 20 seconds. This undoubtedly puts strict requirements on the stability of the bank payment business system, and some banks even adopt a "zero tolerance" attitude towards "accounting errors" in payment business.

[0003] The stable operation of software programs is subject to various factors, covering hardware, middleware, personnel, and system and data changes. In terms of hardware, the performance and stability of servers, networks and other devices are crucial; in terms of middleware, the reliable operation of databases, operating systems and other systems is the foundation; in terms of personnel, the professional level of operation and maintenance personnel directly affects system operation; at the same time, the rationality of system changes and data changes cannot be ignored.

[0004] In view of the fact that a single software cannot independently achieve significant improvement in stability, since the birth of payment business systems in 1991, various payment business systems have generally relied on software engineering management methods to avoid "accounting errors". Common methods include:

[0005] Design document review: internal and external reviews are carried out to ensure the scientificity, rationality and completeness of the design document.

[0006] Development code review: through internal and external reviews, the development code is strictly controlled to improve the code quality.

[0007] Multiple rounds of testing: multiple rounds of integration testing and user testing are carried out to thoroughly investigate potential problems and ensure system functionality and performance.

[0008] Accounting and auditing: a daily end-of-day reconciliation function is added to the payment system, and an audit system is added for post-tracing to ensure the accuracy and completeness of transaction data.

[0009] Disaster recovery deployment: cluster deployment of the system and a two-site three-center disaster recovery solution are adopted to enhance the fault tolerance and availability of the system.

[0010] Monitoring and early warning: deploy daily monitoring and early warning software to monitor system operation in real time and promptly discover and handle abnormal situations.

[0011] Operation and maintenance safety management: develop and implement a daily operation and maintenance safety management plan to ensure the safety and standardization of the system operation and maintenance process.

[0012] Although the current conventional payment service system is to prevent the "accounting error" problem, a variety of verification and protection means are taken for the "code logic" of the service system, such as Figure 6 However, in the actual production environment, the accounting problem is still mostly concentrated in the core "code logic" level, and various protection measures have failed to effectively play the expected role. The reason is that the payment business itself has high complexity and professionalism, which makes its code logic not only complex, but also relatively fragile, such as Figure 7 As shown in the figure, this flow contains a large number of logical judgments, process loops, and process jump links. In the conventional payment service system, there are usually more than 100 transaction types similar to the above, and the system is updated once a month. During system operation, whether it is version upgrade, hardware failure, network fluctuation, middleware defects, or human operation error, it may cause the above process exception, and thus cause serious "accounting error" problem.

[0013] Therefore, the existing payment service system has the following outstanding problems in preventing "accounting error":

[0014] (1) Quality control failure

[0015] In order to enhance the stability of the system, the system has built a large and multi-level quality control system. However, the actual situation is that production accidents still often occur at the core code logic. The effect of quality management is ultimately subject to factors such as personnel, cost, and time, and it is difficult to do everything, so the final result is that the seemingly complete quality control system is difficult to play a role.

[0016] (2) Core code vulnerability

[0017] The core code of the payment service system faces many severe challenges. It not only has to deal with high-frequency version upgrades, but also has to withstand hardware failures, network fluctuations, middleware defects, and human operation errors. At the same time, the logic of the core code itself is extremely complex, like a delicate and fragile instrument, and a slight fault can cause its logic processing to be wrong. In view of this, most banks can only require the payment business system supplier to provide a version that has been used in the production environment of multiple banks, hoping to reduce risks through this "proven" version.

[0018] (3) System upgrade difficulty

[0019] The core code of the payment service system is difficult to run stably in a harsh environment, which makes commercial banks have to increase the investment in hardware and operation and maintenance. However, with the increasingly fierce market competition, the bank payment business needs to be iteratively upgraded, and the monthly version update inevitably modifies the payment service system. However, different banks will form different versions in the modification process, and cannot learn from the experience of other banks, so all risks can only be borne alone. Therefore, when the new change is large, the bank often chooses to delay the version online, or even cancel the version upgrade. In the long run, the bank may miss important market opportunities and be at a disadvantage in the fierce market competition.

[0020] Therefore, there is an urgent need for a payment security method that minimizes the risk of transactions caused by core code problems or external interference. SUMMARY

[0021] To solve the above problems, the application provides a payment security method and device based on double-system auditing, which can monitor and intercept potential financial risks in real time, and ensure the safe and stable operation of payment business.

[0022] To achieve the above purpose, the application provides a payment security method based on double-system auditing, which includes:

[0023] The upstream system calls the payment service system to initiate a payment instruction according to the payment business demand;

[0024] The business logic processing module in the payment service system verifies the payment instruction and executes payment business processing operation according to the predetermined code logic;

[0025] The payment service system calls the accounting system to complete the accounting according to the processing logic, and generates a payment text;

[0026] The verification system verifies the processing result of the business logic processing module for rationality, and if the verification fails, the payment text is intercepted;

[0027] If the verification passes, the payment service system sends an accounting instruction to the accounting system and sends the payment text to the payment channel;

[0028] The payment channel receives the payment text and completes the payment process.

[0029] As a further improvement of the application, the payment service system calls the accounting system to complete the accounting according to the processing logic, which includes:

[0030] According to the payment instruction, the verification and processing operation is performed according to the established code logic, and a payment service processing result is obtained, including a payment text of payment service processing success or processing failure, and a bank account system is called to complete the accounting to obtain an accounting result.

[0031] As a further improvement of the application, the processing result of the business logic processing module is verified for rationality, including:

[0032] The logical rationality between the accounting result and the payment text is verified.

[0033] As a further improvement of the application, when the payment service processing result is the payment text of payment service processing failure and the accounting result, it is verified whether the accounting result is accounting failure, and if it is accounting failure, the logical rationality between the accounting result and the payment text is verified.

[0034] Otherwise, the logical rationality between the accounting result and the payment text is not verified.

[0035] As a further improvement of the application, when the payment service processing result is the payment text of payment service processing success and the accounting result, it is verified whether the accounting result is accounting success, and if it is accounting success, the logical rationality between the accounting result and the payment text is verified.

[0036] Otherwise, the logical rationality between the accounting result and the payment text is not verified.

[0037] As a further improvement of the application, the business processing system is developed according to the customer demand to realize the business logic processing module, and the verification system is developed according to the industry standard to realize the rationality verification.

[0038] As a further improvement of the application, the first business requirement specification is written according to the customer demand to complete the system function, and the software engineer converts the design content into computer program code according to the first business requirement specification to obtain the developed business processing system.

[0039] As a further improvement of the application, the second business requirement specification is written according to the industry standard, and the software engineer develops the framework code of the verification system according to the second business requirement specification, and the bank business supervisor configures the verification rules in the framework code to obtain the verification system.

[0040] The application also provides a payment security device based on a double-system auditing type, which comprises a service access module, a business verification process module, a verification rule library and a service access module.

[0041] The service access module is used to:

[0042] The SDK and HTTP access mode are provided to connect with the payment service system.

[0043] The business verification process module is used for:

[0044] Integrating multiple standard verification processes of payment business, and performing the standard verification processes according to the rules in the verification rule library;

[0045] The verification rule library is used for:

[0046] Being stored in the system in a parameterized form, and performing rationality verification on the processing result of the business logic processing module in combination with the business verification process module;

[0047] The service interface module is used for:

[0048] Connecting an accounting system and a payment channel, obtaining basic information to perform related verification, including accounting result verification and payment clearing result verification.

[0049] As a further improvement of the present application, a firewall system is further included, which provides a running environment for the verification rule library.

[0050] Compared with the prior art, the present application has the following beneficial effects:

[0051] The present application uses two sets of completely independent systems to perform verification work for the same payment fund transaction. Only when the verification results of the two sets of systems are consistent, the transaction is determined to be successful. This mechanism can greatly enhance the stability of the payment system.

[0052] The present application has the ability to accurately identify and effectively intercept defects caused by insufficient payment business code testing, can successfully prevent abnormal transactions caused by such defects, and can cope with system defect risks. For errors that occur during data changes, version deployment and other operations by operation and maintenance personnel, the present application can timely detect and intercept error transactions caused by operation errors, and can cope with operation error risks. When the middleware such as database, container, cloud platform and virtual machine fails, causing the system to stop suddenly, the present application can effectively intercept abnormal end transactions caused by middleware failure, and can cope with middleware failure risks. In the face of abnormal transaction situations caused by operating system shutdown, file system failure and other problems, the present application has a reliable interception mechanism and can prevent such abnormal transactions from occurring, and can cope with operating system failure risks. For abnormal transactions caused by hardware and network problems such as disk array shutdown, network disconnection and network card failure, the present application can also effectively intercept, and can cope with hardware and network failure risks.

[0053] The application is easy to standardize, and the check rule library constructed by the application strictly follows the industry standard specification, which is a universally recognized and jointly observed criterion in the field of commercial banks. Based on this, a standardized rule library can be formed for all commercial banks to share. In the "account sending" link of most banks, three key conditions of "account status = success", "transaction agency = account agency" and "transaction amount = account amount" need to be verified. This verification process aims to confirm whether the payer amount has been successfully deducted, and to ensure the consistency of the transaction agency and the account agency, and the accurate matching of the transaction amount and the account amount. Therefore, once the configuration of such rules is completed in the first bank, all subsequent banks can directly reuse, thereby gradually forming a standardized business rule system. This not only helps to reduce the use cost of each bank, but also builds a solid security barrier in the banking industry, which is helpful for the healthy development of the entire financial industry.

[0054] The application has significant cost-effectiveness. The double-system construction scheme is not a literal "construction of two independent systems", which is costly and difficult for most commercial banks to bear. Therefore, the application innovatively constructs a "verification system" to efficiently verify the "relatively constant business specification" through "verification rules". This design not only greatly reduces the initial construction cost, but also significantly reduces the maintenance cost because the business specification is relatively stable and does not need to be frequently adjusted due to normal business changes. Specifically, in the "account sending" link of most banks, as long as the business specification of the People's Bank for the super online banking system does not change significantly, the business changes of the commercial bank itself usually do not require modification of the three rules of "account status = success", "transaction agency = account agency" and "transaction amount = account amount" that need to be verified. These rules can be copied from the successful experience of other commercial banks in the early construction stage, and remain basically stable in the maintenance process without frequent changes. Therefore, the construction and maintenance cost of the application method and device is extremely low, which does not bring additional burden to the construction of payment type business system, and is more suitable for large-scale promotion of commercial banks. BRIEF DESCRIPTION OF DRAWINGS

[0055] Figure 1 A payment security method flowchart based on a double-system auditing type is disclosed for an embodiment of the application;

[0056] Figure 2 A payment security method logic block diagram based on a double-system auditing type is disclosed for an embodiment of the application;

[0057] Figure 3 A mutual independent business processing system and verification system construction method schematic diagram is disclosed for an embodiment of the application;

[0058] Figure 4A payment security device function architecture based on a dual-system auditing type is disclosed for an embodiment of the present application.

[0059] Figure 5 A flowchart of a payment security method based on a dual-system auditing type for general remittance business is disclosed for an embodiment of the present application.

[0060] Figure 6 A schematic diagram of various verification protection measures currently taken for core code logic of a business system is disclosed as background art of the present application.

[0061] Figure 7 A typical payment and payment business scenario logic diagram is disclosed as background art of the present application. DETAILED DESCRIPTION

[0062] 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 below in connection with the drawings of the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0063] The present application will be described in further detail below in connection with the drawings:

[0064] As shown in Figure 1 , 2 A payment security method based on a dual-system auditing type is provided by the present application. In a conventional payment business system, when processing financial business, the process usually starts from a payment application initiated by an "upstream system" (such as a counter system, an online banking system, a mobile banking system, etc.). Subsequently, a payment business system intervenes to process business, and in this process, it calls an "accounting system" (such as a core business system, a card system, etc.) to complete the accounting operation. Finally, along with the sending of a payment message, the entire payment process is completed. However, when the payment system processes special business or encounters external interference, if its business processing logic is wrong, it may generate unreliable accounting instructions or payment messages, thereby causing serious "accounting errors".

[0065] In this mode, for large amount of business, there is a high efficient audit mode in the actual business operation of the bank, that is, two clerks are arranged to respectively perform transaction input, one clerk is responsible for initial input, and the other clerk is responsible for secondary input according to the original voucher, and only when the processing results of the two times of input are completely consistent, the transaction is considered to be valid and ends normally; therefore, the present application proposes a double system improvement scheme of “business + verification”, two completely independent systems are adopted to verify the same financial transaction, and only when the verification results of the two systems are consistent, the transaction is considered to be successful, which specifically includes:

[0066] S1, the upstream system calls the payment business system to initiate a payment instruction according to the payment business demand;

[0067] Among them,

[0068] When the upstream system has payment business demand, the payment service provided by the payment business system is called to initiate a payment instruction.

[0069] S2, the business logic processing module in the payment business system verifies the payment instruction and executes the payment business processing operation according to the predetermined code logic, and the payment business system calls the account system to complete the accounting according to the processing logic;

[0070] Among them,

[0071] The business processing module of the payment business system verifies the rationality and safety of the payment instruction;

[0072] According to the payment instruction, the verification and processing operation are executed according to the predetermined code logic, and the payment business processing result is obtained, including the payment text of payment business processing success or failure, and the account system is called to complete the accounting to obtain the accounting result;

[0073] Specifically,

[0074] In a conventional case, the payment business system calls the account system to perform accounting, and sends a payment instruction to the payment channel. However, if the payment code logic fails due to various reasons at this time, the accounting instruction sent by the payment business system to the account system and the payment instruction sent to the payment channel will become unreliable. For example, the payment business system has a hot account function, if the parallel account entry speed of a single account exceeds 50 per second, the payment business system will report an error “11002-account accounting busy, start idempotent processing”. But the payment business system code does not add special processing mechanism for this error condition, and directly judges as accounting failure, and replies to the payment channel with “processing failure” payment text. After a period of time, the payment business system processing is successful, but the payment is identified as a failure, which finally leads to serious accounting error.

[0075] S3, verifying the rationality of the processing result of the service logic processing module, if the verification fails, intercepting the payment message;

[0076] wherein,

[0077] verifying the logical rationality between the accounting result and the payment message.

[0078] Further,

[0079] In the example in S2, before replying to the payment channel with a payment message indicating processing failure, the accounting result of the payment service system must be accounting failure, and cannot be accounting idempotency. Once it is found that the requirement is not met, the payment instruction will be directly intercepted, thereby effectively preventing the occurrence of such accounting errors.

[0080] Specifically,

[0081] When the payment service processing result is a payment message indicating payment service processing failure and an accounting result, verify whether the accounting result is accounting failure, if it is accounting failure, the logical rationality between the accounting result and the payment message;

[0082] Otherwise, the logic between the accounting result and the payment message is not reasonable.

[0083] When the payment service processing result is a payment message indicating payment service processing success and an accounting result, verify whether the accounting result is accounting success, if it is accounting success, the logical rationality between the accounting result and the payment message;

[0084] Otherwise, the logic between the accounting result and the payment message is not reasonable.

[0085] S4, if the verification passes, the payment service system sends a payment message to the payment channel;

[0086] wherein,

[0087] After rationality verification, the payment message sent to the payment channel indicating processing success is a safe and reliable payment message.

[0088] S5, the payment channel receives the payment message, completing a safe and reliable payment process.

[0089] After the standard payment process of S1-S5, the payment channel receives a safe and reliable payment message, greatly reducing the business risk caused by the problem of the payment message. The accounting system receives a safe and reliable accounting instruction, ensuring the accuracy and stability of the accounting process.

[0090] The double-system auditing payment security method is realized at a logical level by S1-S5 in the application, which ensures the feasibility of the double-system auditing payment security method by avoiding the same business requirements, the same design architecture, and the same batch of developers in the field of software engineering, and ensuring that the codes written by the developers are highly similar, so that the two systems are almost identical, as shown in Figure 3 In the application, the business logic processing module and the rationality verification part are designed as one system respectively, and two systems must adopt completely different standards and process flows from demand analysis, design planning to development and implementation. Only in this way, two truly independent and complementary systems can be built, so that potential accounting errors can be effectively identified and intercepted in the financial transaction processing process, and the safety and stable operation of financial business are ensured.

[0091] Among them,

[0092] As shown in Figure 3 , the business processing system is developed to realize the function of the business logic processing module, and the verification system is developed to realize the function of the rationality verification part.

[0093] Further,

[0094] (1) Set the target difference between the business processing system and the verification system:

[0095] The business processing system focuses on building a "business processing system that can be changed frequently according to business requirements" to flexibly adapt to changing business scenarios and customer needs.

[0096] The verification system is to build a "safe and reliable verification system that can be changed infrequently according to industry standards and standards", which focuses on ensuring the security and compliance of financial transactions, and ensures that each transaction meets industry regulations.

[0097] (2) Set the specification difference between the business processing system and the verification system

[0098] In the P001-1 demand stage, the business processing system carefully organizes the specific requirements provided by the customer to form a "certain business-demand specification document". This document will become the functional target guide for the development of the core code of the business processing system, ensuring that the system functions can accurately meet customer requirements.

[0099] Verification system, also in P002-1 demand stage, but at this time the demand is not by the customer, but by the industry standards as the basis for the demand specification. For example, payment settlement method as the payment specification of the People's Bank, is the standard that all payment systems must comply with. In addition, different payment services have corresponding payment channel message standards, which are usually announced by the People's Bank or the financial management department. Since industry standards mainly exist in the form of rules and do not involve detailed functional points, their demand content is greatly reduced compared to the function range of "some business-demand specification", which fundamentally reduces the construction cost of verification system.

[0100] (3) Design differences between business processing system and verification system

[0101] Business processing system, in P001-2 design stage, according to the demand specification in P001-1 stage, to complete the system function as the core target, to write "some business-detailed design specification", to provide detailed design blueprint for the follow-up development work.

[0102] Verification system, P002-2 stage is also a design stage, but at this time the design is based on the industry standard in P002-1 stage, to write "some verification module-detailed design specification", to ensure that the design of the verification module meets the industry standards and safety requirements.

[0103] (4) Differences between developers of business processing system and verification system

[0104] Business processing system, P001-3 is the development stage, software engineers will convert the design content into actual computer program code according to the detailed design specification in P001-2 stage. After strict testing and verification, the system is put into production environment, responsible for processing actual payment business.

[0105] Verification system, P002-3 is also in the development stage, but software engineers only develop the framework code of the verification module in this stage, without writing verification rules directly into the code. Instead, the bank business supervisor configures the "verification rules" into the system, which is released to the production system after testing.

[0106] And the "verification rules" produced in P002-3 stage have industry-wide applicability, suitable for most banks. Through multiple verification and optimization, it can avoid the problem of insufficient capacity of a single supervisor, forming a widely, stable, efficient rule library, like a solid firewall, providing reliable security protection for banks.

[0107] Specifically,

[0108] According to the customer's demand to develop business processing system to realize business logic processing module, and develop verification system according to industry standards to realize rationality verification.

[0109] Wherein,

[0110] According to the customer demand, the first business requirement specification is written to complete the system function as the target, and the software engineer converts the design content into computer program code to obtain the development business processing system according to the first business requirement specification.

[0111] The second business requirement specification is written according to the industry specification, the framework code of the verification system is developed by the software engineer according to the second business requirement specification, and the bank business supervisor configures the verification rules in the framework code to obtain the verification system.

[0112] Finally, the development method of the business processing system and the verification system makes the two systems truly independent and complementary, and can effectively reduce the investment cost of the verification system and avoid double system construction cost expenditure caused by building the verification system.

[0113] As shown in the figure, the application also provides a payment security device based on a double-system auditing type, comprising a service access module, a business verification process module, a verification rule library and a service access module. Figure 4

[0114] The service access module is used for:

[0115] providing SDK and HTTP access mode, and connecting with the payment business system;

[0116] Wherein,

[0117] The two flexible access modes of SDK and HTTP can meet the access requirements of different systems. For the homogeneous system, the SDK mode is recommended to access, which can maximize the transaction processing performance and ensure the efficient operation of the business. And for the heterogeneous system, the HTTP mode can be used to access and realize flexible connection.

[0118] The business verification process module is used for:

[0119] integrating various standard verification processes of the payment business, and executing the standard verification process according to the rules in the verification rule library;

[0120] Wherein,

[0121] ​The business verification process is a core function module of the payment firewall, which integrates multiple standard verification processes commonly used in payment business. Taking the "message number ibps.101.001.02-Internet bank debit business message" as an example, the "debit sending business" standard process will be used, which usually includes multiple links such as "sending pre-verification account status", "verification of people's bank status when reversing", "verification of people's bank status when repeating sending", "verification of people's bank status when canceling", etc. These processes will be strictly executed according to the rules configured in the "verification rule library", to ensure that each transaction meets the business specifications and security requirements.

[0122] The verification rule library is used for:

[0123] Stored in the system in a parameterized form, combined with the business verification process module, to reasonably verify the processing results of the business logic processing module;

[0124] Among them,

[0125] The verification rule library exists in the system in a parameterized form, which is convenient for flexible configuration and adjustment. In the verification rules of the super Internet bank payment system, for the ibps.101.001.02-Internet bank debit business message, according to the payment business specifications, the bank should deduct the transaction amount of the payer when initiating this message, and the receiving bank should identify the amount as "available for the payer's transaction amount" after confirming that the information is correct. Therefore, when the message is sent, the system needs to verify that "account status=success, transaction institution=accounting institution, transaction amount=accounting amount", that is, whether the payer's amount has been successfully deducted, and whether the transaction institution and the accounting institution are consistent, and whether the transaction amount should be consistent with the accounting amount.

[0126] The service interface module is used for:

[0127] Connecting the accounting system and the payment channel, obtaining basic information for related verification, including account result verification and payment clearing result verification.

[0128] Among them,

[0129] Since the "accounting error" in the payment business system mainly occurs in the "accounting system" and "payment channel", the commonly used interface system for verification rule execution includes "accounting result verification" and "payment clearing result verification". Among them, "accounting result verification" is mainly used to verify whether the accounting is successful, the amount is consistent, the institution is matched, etc.; "payment clearing result verification" is mainly used to verify whether this message has been cleared, whether it has failed, whether it is repeated, whether it is abnormal, etc. Basic information is obtained through the service interface, which is used to execute the verification rules.

[0130] The device of the application further comprises a firewall system, which provides a running environment for the verification rule library.

[0131] Embodiment:

[0132] The device of the present application cooperates with the existing payment service system (i.e. service logic processing module) as a rationality verification part. Taking the most representative A100-ordinary remittance service as an example, the specific process is as shown in Figure 5 , which includes:

[0133] S001, remittance application

[0134] The front desk system receives the customer's remittance application, fills in the transaction elements (such as the payer's account number, the payee's account number, the amount, etc.), and initiates a call to the payment service processing system interface.

[0135] S002, verification of payee and payer information

[0136] The payment service processing system checks the validity of the payer's and payee's accounts (such as whether the account number exists, whether the account status is normal).

[0137] S003, verification of sender and receiver bank information

[0138] The sender bank and receiver bank institution code and clearing channel configuration are checked to ensure that the bank number matches the clearing system.

[0139] S004, verification of remittance amount and limit

[0140] The available balance of the payer's account, the consistency of the currency, and the account limit are checked.

[0141] S005, call the account system to deduct the account

[0142] After verification, the payment service processing system saves the transaction information and calls the core business system to initiate the account deduction.

[0143] S006, payer account deduction processing

[0144] The core business system performs the account deduction operation and returns the account deduction result (success / failure) and transaction serial number.

[0145] S007, core account registration result

[0146] The payment service processing system records the account deduction status, account registration institution, account registration amount, and other key information returned by the core.

[0147] S008, organization of payment message

[0148] If the core account registration is successful, the payment service processing system assembles the message according to the payment message standard (such as ISO 20022).

[0149] S009, payment firewall verification trigger

[0150] The payment service processing system calls the payment firewall API, submits transaction information and core accounting results.

[0151] S010, obtain verification rules from the rule library

[0152] The payment firewall system loads corresponding verification rules (such as: accounting status = success, transaction institution = accounting institution, transaction amount = accounting amount) from the rule library according to the transaction type (A100-general exchange).

[0153] S011, execute verification rules

[0154] The payment firewall performs multi-dimensional verification according to the rule engine, including:

[0155] Core accounting status consistency (whether the payment has been deducted)

[0156] Transaction institution and accounting institution matching

[0157] Transaction amount and accounting amount equivalence (excluding fee difference)

[0158] S012, verification result return

[0159] The payment firewall returns the verification result (pass / fail) and risk information (such as "transaction suspended, accounting error risk found").

[0160] S013, payment message sending decision

[0161] If the verification fails, the payment service processing system terminates the transaction and triggers a risk warning (such as sending a short message to the teller and generating an abnormal work order).

[0162] If the verification passes, the payment service processing system submits the message to the People's Bank payment channel (such as the large-value payment system).

[0163] S014, payment message sending receiving bank

[0164] The payment service processing system sends the message to the receiving bank through the clearing channel (such as CNAPS) and records the sending status.

[0165] Advantages of the present application:

[0166] The present application uses two sets of completely independent systems to carry out verification work for the same payment fund transaction. Only when the verification results of the two systems are consistent, the transaction will be determined to be successful. This mechanism can greatly enhance the stability of the payment system.

[0167] The present application has the ability of accurate identification and effective interception, can successfully prevent abnormal transactions caused by such defects, and can cope with system defect risks. For errors made by operation and maintenance personnel during data change, version deployment and other operations, the present application can timely detect and intercept error transactions caused by operation errors, and can cope with operation error risks. When the middleware such as database, container, cloud platform and virtual machine fails, causing the system to stop suddenly, the present application can effectively intercept abnormal end transactions caused by middleware failure, and can cope with middleware failure risks. In the face of abnormal transaction situations caused by operating system shutdown, file system failure and the like, the present application has a reliable interception mechanism, can prevent such abnormal transactions, and can cope with operating system failure risks. For abnormal transactions caused by hardware and network problems such as disk array shutdown, network disconnection and network card failure, the present application can also effectively intercept, and can cope with hardware and network failure risks.

[0168] The present application is easy to standardize, and the check rule library constructed by the present application strictly follows industry standard specifications, which are universally recognized and jointly observed in the field of commercial banks. Based on this, we can form a standardized rule library for all commercial banks to share. In the "send to account" link of most banks, three key conditions of "account status = success", "transaction agency = account agency" and "transaction amount = account amount" need to be verified. This verification process aims to confirm whether the payer amount has been successfully deducted, and to ensure the consistency of the transaction agency and the account agency, and the accurate matching of the transaction amount and the account amount. Therefore, once the configuration of such rules is completed in the first bank, all subsequent banks can directly reuse, thereby gradually forming a standardized business rule system. This not only helps to reduce the use cost of each bank, but also builds a solid security barrier in the banking industry, which is helpful for the healthy development of the entire financial industry.

[0169] The cost-effectiveness of the present application is remarkable, and the dual-system construction scheme is not in the literal sense of "constructing two independent systems", which is costly and difficult for most commercial banks to bear. Therefore, the present application innovatively constructs a set of "verification system" to efficiently verify the "relatively constant business specifications" through "verification rules". This design not only greatly reduces the initial construction cost, but also significantly reduces the maintenance cost because the business specifications are relatively stable and do not need to be frequently adjusted due to normal business changes. Specifically, in the "sending to account" link of most banks, as long as the People's Bank does not make major adjustments to the business specifications of the super online banking system, the commercial bank's own business changes usually do not require modification of the three rules that need to be verified in this link: "account status = success", "transaction agency = account agency" and "transaction amount = account amount". These rules can be copied from the successful experience of other commercial banks at the initial stage of construction, and remain basically stable during maintenance without frequent changes. Therefore, the construction and maintenance cost of the present application method and device is extremely low, which does not bring additional burden to the construction of payment-type business system, and is more suitable for large-scale promotion by commercial banks.

[0170] The present application device builds a strong firewall for the payment business system, and significantly enhances the stability of the payment business system.

[0171] The above is only the preferred embodiment of the present application and is not used to limit the present application. For those skilled in the art, the present application can have various changes and variations. Any modification, equivalent replacement, improvement, etc. within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A dual system audit-based payment security method, characterized by, The application comprises: An upstream system calls a payment service system to initiate a payment instruction according to payment service requirements; A service logic processing module in the payment service system verifies the payment instruction and executes payment service processing operations according to predetermined code logic; The payment service system calls an account system to complete bookkeeping according to processing logic and generates a payment message; A verification system verifies the processing result of the service logic processing module for rationality, and if the verification fails, the payment message is intercepted; If the verification passes, the payment service system sends the payment message to a payment channel; The payment channel receives the payment message and completes the payment process.

2. The dual system audit-based payment security method of claim 1, wherein: The payment service system calls an account system to complete bookkeeping according to processing logic, including: According to the payment instruction, the verification and processing operations are performed according to the predetermined code logic to obtain the payment service processing result, including the payment service processing success or failure payment message, and the account system is called to complete bookkeeping to obtain the bookkeeping result.

3. The dual system audit-based payment security method of claim 2, wherein: The verification system verifies the processing result of the service logic processing module for rationality, including: Verify the logical rationality between the bookkeeping result and the payment message.

4. The dual system audit-based payment security method of claim 3, wherein: When the payment service processing result is the payment service processing failure payment message and the bookkeeping result, verify whether the bookkeeping result is a bookkeeping failure, if it is a bookkeeping failure, the logic between the bookkeeping result and the payment message is reasonable; Otherwise, the logic between the bookkeeping result and the payment message is unreasonable.

5. The dual system audit-based payment security method of claim 3, wherein: When the payment service processing result is the payment service processing success payment message and the bookkeeping result, verify whether the bookkeeping result is a bookkeeping success, if it is a bookkeeping success, the logic between the bookkeeping result and the payment message is reasonable; Otherwise, the logic between the bookkeeping result and the payment message is unreasonable.

6. The dual system audit-based payment security method of claim 1, wherein: According to customer requirements, develop a service processing system to realize a service logic processing module, and develop a verification system to realize rationality verification according to industry specifications.

7. The dual system audit-based payment security method of claim 6, wherein: According to customer requirements, write a first business requirement specification to achieve system functions, and software engineers convert the design content of the first business requirement specification into computer program code to obtain a developed service processing system.

8. The dual system audit-based payment security method of claim 6, wherein: According to industry specifications, write a second business requirement specification, and software engineers develop a framework code of the verification system according to the second business requirement specification, and bank service supervisors configure verification rules in the framework code to obtain the verification system.

9. A dual system review-based payment security device for implementing the dual system review-based payment security method according to any one of claims 1 to 8, characterized by The application comprises: A service access module, a business verification process module, a verification rule library, and a service access module; The service access module is configured to: Provide SDK and HTTP access methods to connect with the payment service system; The business verification process module is configured to: Integrate multiple standard verification processes of payment services, and execute the standard verification processes according to the rules in the verification rule library; The verification rule library is configured to: Be stored in the system in a parameterized form, and verify the processing result of the service logic processing module for rationality in combination with the business verification process module; The service access module is configured to: Connect the accounting system and the payment channel, obtain basic information to carry out relevant verification, including accounting result verification and payment clearing result verification.

10. The dual system review based payment security device of claim 9, wherein: Also included is a firewall system that provides an operating environment for the verification rule base.

Images