Payment and settlement system architecture model construction method and device, electronic equipment and medium

Abstract

The invention discloses a payment and settlement system architecture model construction method and device, electronic equipment and a medium. The method comprises the steps of determining an event model layer; the event model layer is used for determining candidate events required by business transactions, and the candidate events are used for abstractly describing the business transactions; determining a service unit combination layer; the service unit combination layer is used for determining candidate service units, and the candidate service units are used for abstractly describing business transaction processing operation; determining a service unit operation mapping layer; the service unit operation mapping layer is used for determining an association relationship between an operation interface corresponding to a candidate service unit and a candidate operation template; determining an operation template implementation layer; and the operation template implementation layer is used for determining candidate operation templates, and the candidate operation templates are used for executing business transactions. According to the technical scheme, by designing the four-layer architecture model, the development complexity of the payment settlement system can be reduced, and the overall development efficiency can be improved.

Description

Technical Field

[0001] The present invention relates to the field of model building technology, and in particular to a method, device, electronic device, and medium for building a payment and settlement system architecture model. Background Art

[0002] A bank's payment and settlement system is a crucial piece of infrastructure, providing clearing and settlement services for various financial products and diverse types of bank customers. Different types of transactions require information exchange with target banks through the sending and receiving of different types of messages to complete the entire transaction lifecycle. Therefore, the core functionality of the payment and settlement system lies in generating and sending various messages to target banks based on transaction instructions initiated at the bank's counters and through internal systems. It also receives responses from target banks and forwards various business messages from other banks or participating institutions. These two processes simultaneously complete clearing and settlement of funds with target banks and customers.

[0003] Since different types of businesses have certain differences and commonalities in the message types used, the internal funds processing procedures, and the message interaction procedures with the target bank, and various types of transactions have certain similarities and paradigms in the message sending and receiving processing, account processing, and other business links, the most common and direct way to implement the system is to directly write business logic processing for various types of message sending and receiving, and drive the business process through the processing of messages with different numbers.

[0004] As a result, the business processes and system implementations for different transactions lack a top-level abstraction layer of business logic, requiring direct interaction with the specifics of business and messaging standards. The commonalities and differences within different business logics cannot be effectively extracted and expressed. Whenever a new business category is added, it's impossible to quickly extract the business paradigms and logical models within existing code assets to guide rapid development. Summary of the Invention

[0005] The present invention provides a method, device, electronic device and medium for constructing a payment and settlement system architecture model. By designing a four-layer architecture model, the functions of different types of business in the system are defined, described and implemented layer by layer from top to bottom, from abstract to concrete. By decomposing layer by layer, the complex processes and complex component branch logic in the system are effectively decomposed and decoupled into each layer of the model, and the business is accurately described using a unified model language, which can effectively improve the readability and comprehensibility of the system program, thereby reducing the complexity of payment and settlement system development and improving overall development efficiency.

[0006] According to one aspect of the present invention, a method for constructing a payment and settlement system architecture model is provided, the method comprising:

[0007] Determine an event model layer; the event model layer is connected to the service unit combination layer and is used to determine candidate events required for business transactions, and the candidate events are used to abstractly describe business transactions;

[0008] Determining a service unit combination layer; the service unit combination layer is connected to the service unit operation mapping layer and is used to determine candidate service units, wherein the candidate service units are used to abstractly describe business transaction processing operations;

[0009] Determine a service unit operation mapping layer; the service unit operation mapping layer is connected to the operation template implementation layer and is used to determine the association relationship between the operation interface corresponding to the candidate service unit and the candidate operation template;

[0010] Determine an operation template implementation layer; the operation template implementation layer is used to determine candidate operation templates, and the candidate operation templates are used to execute business transactions.

[0011] According to another aspect of the present invention, a device for constructing a payment and settlement system architecture model is provided, the device comprising:

[0012] An event model layer determination module, configured to determine an event model layer; the event model layer is connected to the service unit combination layer and configured to determine candidate events required for a business transaction, wherein the candidate events are used to abstractly describe the business transaction;

[0013] a service unit combination layer determination module, configured to determine a service unit combination layer; the service unit combination layer being connected to the service unit operation mapping layer and configured to determine candidate service units, the candidate service units being configured to abstractly describe business transaction processing operations;

[0014] A service unit operation mapping layer determination module is used to determine a service unit operation mapping layer; the service unit operation mapping layer is connected to the operation template implementation layer and is used to determine the association relationship between the operation interface corresponding to the candidate service unit and the candidate operation template;

[0015] The operation template implementation layer determination module is used to determine the operation template implementation layer; the operation template implementation layer is used to determine candidate operation templates, and the candidate operation templates are used to execute business transactions.

[0016] According to another aspect of the present invention, an electronic device is provided, comprising:

[0017] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the payment settlement system architecture model construction method described in any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the payment settlement system architecture model construction method described in any embodiment of the present invention when executed.

[0019] The technical solution of the embodiment of the present invention determines the event model layer, service unit combination layer, service unit operation mapping layer, and operation template implementation layer, and constructs a four-layer payment settlement system architecture model based on the event model layer, service unit combination layer, service unit operation mapping layer, and operation template implementation layer. This technical solution defines, describes, and implements the functions of different types of business in the system from top to bottom, from abstract to concrete, layer by layer. By decomposing layer by layer, it effectively decomposes and decouples the complex processes and complex component branch logic in the system into each layer of the model, and uses the model's unified language to accurately describe the business, which can effectively improve the readability and comprehensibility of the system's programs, thereby reducing the complexity of payment settlement system development and improving overall development efficiency. It effectively solves the problem that existing payment settlement systems cannot quickly extract business paradigms and logical models from existing code assets to guide rapid development.

[0020] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0022] Figure 1 This is a flowchart of a method for constructing a payment and settlement system architecture model according to the first embodiment of the present invention;

[0023] Figure 2 This is a flowchart of the payer event of a common credit business provided in Example 1 of this application;

[0024] Figure 3This is a flowchart of the events of the ordinary credit business payee provided in Example 1 of this application;

[0025] Figure 4 This is a flowchart of the payer event of the real-time credit service provided in Example 1 of this application;

[0026] Figure 5 This is a flowchart of the real-time credit service payee event provided in Example 1 of this application;

[0027] Figure 6 Schematic diagram of the decomposition of the ordinary credit business service unit provided in Example 1 of this application;

[0028] Figure 7 A schematic diagram of splitting a common credit service unit provided in Example 1 of the present application;

[0029] Figure 8 A flowchart of the splitting of the real-time credit service unit provided in Example 1 of this application;

[0030] Figure 9 A schematic diagram of splitting another real-time credit service unit provided in Example 1 of the present application;

[0031] Figure 10 Flowchart of the application of the payment and settlement system architecture model provided in the second embodiment of the present invention;

[0032] Figure 11 A schematic diagram of a payment settlement system model application provided in Example 2 of the present application;

[0033] Figure 12 2 is a schematic diagram of the structure of a device for constructing a payment and settlement system architecture model according to a third embodiment of the present invention;

[0034] Figure 13 It is a structural diagram of an electronic device for implementing the payment settlement system architecture model construction method of an embodiment of the present invention. DETAILED DESCRIPTION

[0035] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0036] It should be noted that the terms "candidate", "target", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or that are inherent to these processes, methods, products or devices.

[0037] Example 1

[0038] Figure 1 This is a flowchart of the method for constructing a payment settlement system architecture model according to the first embodiment of the present invention. This embodiment is applicable to the case of constructing a payment settlement system architecture model. The method can be executed by a payment settlement system architecture model construction device. The payment settlement system architecture model construction device can be implemented in the form of hardware and / or software. The payment settlement system architecture model construction device can be configured in a device. For example, the device can be a background server or other device with communication and computing capabilities. Figure 1 As shown, the method includes:

[0039] S110. Determine an event model layer; the event model layer is connected to the service unit combination layer and is used to determine candidate events required for business transactions, and the candidate events are used to abstractly describe business transactions.

[0040] In this solution, the payment and settlement system is an important infrastructure of the bank, providing funds clearing services for various financial products and different types of bank customers. The core function of the system is to interact with external institutions by receiving or sending various payment messages from the target bank, and to complete the full process of various payment and settlement transactions through complex message interactions. At the same time, it performs account processing for various customer settlement accounts for various transaction scenarios.

[0041] In this embodiment, the event model layer in the payment and settlement system architecture model is used to abstractly describe business transactions and accurately identify and define candidate events required in the business process. The event model layer is connected to the service unit combination layer.

[0042] The candidate events include payer-related events and payee-related events, as shown in Table 1.

[0043] Table 1

[0044]

[0045]

[0046] In this solution, payer-related events include customer temporary deduction events, customer funds freezing events, customer temporary deduction confirmation events, customer temporary deduction confirmation receipt processing events, customer deduction cancellation events, customer clearing deduction events, payment confirmation events, payment clearing events, payment confirmation clearing events, payment clearing receipt events, clearing temporary refund events, deduction payment clearing combination events, customer refund events, counterparty payment confirmation events, clearing notification events, deduction instruction reception events, payment cancellation initiation events, and payment rejection events.

[0047] A temporary deduction event refers to a temporary deduction of a certain amount of funds from a customer's account. This may be due to various temporary reasons, such as temporary deductions of fees stipulated in a contract or temporary fines for violations. For example, a customer may be temporarily deducted a certain amount of money for exceeding the prescribed usage of a service.

[0048] A customer fund freeze occurs when part or all of a customer's account funds are frozen, preventing normal payments, transfers, and other operations. Common causes include fund occupation, judicial freezes, and abnormal account risk management. For example, funds may be occupied during a delayed remittance, or a customer's account may be frozen by the court due to suspected financial disputes.

[0049] A customer temporary deduction confirmation event refers to an event in which the system or relevant personnel confirms the deduction after the customer temporary deduction operation is completed to ensure the accuracy and compliance of the deduction operation.

[0050] The customer temporary deduction confirmation receipt processing event refers to the event that generates a receipt after the customer confirms the temporary deduction and processes this receipt. This processing may include archiving the receipt and sending it to the relevant parties.

[0051] A customer debit cancellation event occurs when an executed customer debit is canceled and the funds are returned to the customer's account. This may be due to a debit error, unanimous agreement between the two parties, or other reasons.

[0052] Customer liquidation deduction events refer to deductions made during the customer account liquidation process, in accordance with relevant rules and agreements. Liquidation may involve fund settlements with other institutions, fee settlements, etc. For example, a bank may deduct related account management fees during the monthly liquidation of a customer's account.

[0053] A payment confirmation event is a confirmation of a payment operation, indicating that the payment has been successfully completed or has entered a specific confirmation state. This can be automatic or manual.

[0054] A payment settlement event refers to the fund settlement process involved in a payment, including fund transfers and settlements with the payee's bank or other financial institution.

[0055] Payment confirmation and settlement events refer to further completing and confirming related settlement operations based on payment confirmation.

[0056] A payment clearing receipt event refers to the receipt information generated after payment clearing is completed. This receipt can be used to confirm the successful completion of the clearing and provide relevant clearing details. For example, a clearing institution (such as the People's Bank of China or SWIFT) sends a clearing message to a participating financial institution, or a bank sends a payment clearing receipt to a company, notifying the recipient of the successful transfer of funds to the recipient's account.

[0057] A temporary refund event during liquidation refers to a temporary refund that is required during the liquidation process due to various reasons (such as transaction cancellation, payment error, etc.). For example, if a problem is discovered with a transaction during liquidation, the paid amount will be temporarily refunded to a temporary account for subsequent processing.

[0058] A combined deduction, payment, and settlement event refers to a combination of events involving deduction, payment, and settlement. In complex business scenarios, multiple operations may occur simultaneously or sequentially.

[0059] A customer refund event is when a customer receives a refund for the money they have already paid.

[0060] A counterparty payment confirmation event refers to the event in which the payee confirms receipt of the payment.

[0061] A liquidation notification event refers to the sending of a liquidation notification to relevant parties during the liquidation process. This notification may include information such as the liquidation time, liquidation amount, and liquidation method. For example, a clearing institution (such as the People's Bank of China or SWIFT) proactively sends transaction funds liquidation results to participating financial institutions, or a bank sends a monthly liquidation notification to its customers, informing them of the liquidation status of their accounts.

[0062] A debit instruction received event occurs when a system or relevant personnel receives an instruction to debit a customer. This instruction may come from an internal business system, an external partner, or a relevant management department. For example, a bank may receive an instruction from the tax department to deduct taxes from a customer's account.

[0063] A payment cancellation event is an event in which the payer proactively cancels a submitted payment operation.

[0064] The claimant rejection event refers to the event in which the claimant's payment request is rejected.

[0065] In this embodiment, events related to the payee include clearing notification events, incoming payment instruction reception events, incoming payment confirmation events, temporary incoming payment collection events, incoming payment confirmation receipt processing events, incoming payment reception confirmation two-in-one events, manual incoming payment entry events, temporary collection transfer events, incoming payment entry events, automatic incoming payment entry events, customer payment request events, payment request cancellation events, and customer payment collection cancellation events.

[0066] Among them, liquidation notification events usually occur in the liquidation stage of financial transactions. It means that the relevant institutions or systems send notifications about fund liquidation to the participants, informing them of the time, amount, transaction details and other information of the liquidation, so that all parties can make fund preparations and account processing.

[0067] The "Receive Incoming Funds Instruction" event occurs when one party receives an instruction from another party to transfer funds to a designated account. This instruction contains relevant information about the incoming funds, such as the payer and recipient, the amount, and the purpose of the transfer. It is the initial instruction for the flow of funds.

[0068] A payment confirmation event is triggered by the recipient confirming the arrival of funds after receiving them. This event verifies the amount, source, and other information to ensure that the funds received are consistent with expectations and confirm that the funds have successfully arrived in the designated account.

[0069] A temporary funds collection event occurs when funds received need to be temporarily held in a transition account or undergo further review and processing. The funds are temporarily collected pending further processing, such as confirming compliance with applicable regulations and whether additional approval processes are required.

[0070] The payment confirmation receipt processing event is the process of processing the payment confirmation receipt. When the payee confirms receipt of the payment, they will send a receipt to the payer. The payer or the relevant system will receive, record, and process this receipt to ensure that both parties are aware of the successful arrival of the funds.

[0071] The two-in-one event of receiving and confirming incoming funds refers to the event triggered by combining the two steps of receiving incoming funds and confirming the incoming funds into one operation or process.

[0072] Manual payment events are those that require manual intervention to record incoming funds into the corresponding account. These events are typically used in situations where special processing is required or the system cannot automatically complete the payment, such as when the nature of the funds is unclear or account information is incorrect, requiring manual verification and processing before the payment is recorded.

[0073] A temporary transfer event is triggered by transferring previously temporarily received funds into a formal account. Once the temporarily received funds have been reviewed or meet certain conditions, they are transferred from the temporary account to the designated formal account, completing the final entry of the funds.

[0074] An incoming payment event is an event triggered by the process of recording received funds into the corresponding account, including different methods such as automatic and manual entry.

[0075] An automatic payment event refers to an event triggered by the automatic recording of funds into the corresponding account upon receipt of funds, based on the system's preset rules and procedures.

[0076] A customer claim event refers to an event triggered by a customer making a request for payment to a relevant institution or other party.

[0077] A claim cancellation event occurs when a customer or related party proactively cancels a previously initiated claim request.

[0078] A customer cancellation of payment usually refers to a situation where a customer proactively terminates an initiated or planned payment during a business transaction or fund flow.

[0079] Specifically, the abstract candidate events required for the business are determined based on the business process, accounting processing process, and clearing process definitions. The capital flow processing process in the transaction life cycle is defined based on the interaction of candidate events, thereby determining the event model layer.

[0080] This solution abstractly describes various discrete transaction entry points within a business transaction. The core of the payment and settlement system is payment clearing services, and candidate events are primarily abstractly described from the perspective of capital flow. These abstract event descriptions can be reused across multiple transaction scenarios within a module or across different business modules.

[0081] For example, Figure 2 This is a flow chart of the payer event of a common credit business provided in Example 1 of this application, such as Figure 2 As shown, the payer events of ordinary credit business mainly include customer temporary deduction event, customer deduction cancellation event, deduction payment settlement combination event, payment confirmation settlement event, payment confirmation settlement event, deduction payment settlement combination event, and payment settlement receipt event. Figure 3 This is a flowchart of the event of the ordinary credit business payee provided in Example 1 of this application, such as Figure 3 As shown, the payee events of ordinary credit business mainly include the event of receiving incoming payment instruction, the event of deduction and payment settlement combination, the event of payment settlement receipt, the event of payment confirmation settlement, the event of deduction and payment settlement combination, the event of automatic payment entry, the event of temporary customer deduction, and the event of manual payment entry. Figure 4 This is a flow chart of the real-time credit service payer event provided in Example 1 of this application, as shown in FIG. Figure 4As shown in the figure, the payer events of the real-time credit business mainly include the payment cancellation instruction sending event, the deduction payment settlement combination event, the settlement notification event, the counterparty receipt confirmation event, the payment settlement receipt event, the settlement notification event, and the counterparty receipt confirmation event. Figure 5 This is a flow chart of the real-time credit service payee event provided in Example 1 of this application, as shown in FIG. Figure 5 As shown, the payee events of the real-time credit business mainly include the two-in-one event of incoming payment receipt confirmation, the event of incoming payment confirmation receipt processing, the event of settlement notification, and the event of manual payment entry.

[0082] S120. Determine a service unit combination layer; the service unit combination layer is connected to the service unit operation mapping layer and is used to determine candidate service units, where the candidate service units are used to abstractly describe business transaction processing operations.

[0083] In this embodiment, the service composition layer in the payment and settlement system architecture model is used to identify candidate service units. These candidate service units are used to abstractly describe subsets of various business processing operations for payers, payees, and senders and receivers in different transactions. Specifically, candidate service units are abstract descriptions from the perspective of messages and business processing.

[0084] In this solution, candidate service units include the Outgoing Message Service, the Incoming Message Service, the CNAPS2 Notification Service, the CNAPS2 Response Service, the Response Service, the Credit Instruction Service, the Credit Instruction Service, the Debit Instruction Service, the Debit Instruction Service, the Counterparty Response Service, the Transaction Cancellation Service, the Transaction Cancellation Service, the Refund Processing Service, the Transaction Forwarding Service, and the Blacklist Scanning Service. CNAPS2 refers to the target bank's second-generation payment system.

[0085] The Outgoing Message Service Unit is responsible for sending messages. The Incoming Message Service Unit is responsible for receiving external messages. The CNAPS2 Notification Service Unit is responsible for receiving notifications from the CNAPS2 system. The CNAPS2 Response Service Unit is responsible for receiving responses from the CNAPS2 system to previous requests or operations. The Response Service Unit is responsible for responding to other systems or requesting parties. The Credit Instruction Service Unit is responsible for receiving credit instructions. The Credit Instruction Service Unit is responsible for sending credit instructions. The Debit Instruction Service Unit is responsible for receiving debit instructions. The Debit Instruction Service Unit is responsible for sending debit instructions. The Counterparty Response Service Unit is responsible for receiving responses from counterparties regarding related transactions. The Transaction Cancellation Service Unit is responsible for canceling an ongoing transaction. The Transaction Cancellation Service Unit is responsible for receiving transaction cancellation instructions from other parties. The Remittance Refund Processing Service Unit is responsible for processing remittance refunds, such as returning received funds to the original payer's account. The Transaction Forwarding Service Unit is responsible for forwarding transaction information to other appropriate systems or processing units. The blacklist scanning service unit is used to scan relevant transactions or business objects to check whether they exist in the blacklist in order to perform risk control and other operations.

[0086] In this embodiment, Figure 6 This is a schematic diagram of the splitting of the ordinary credit business service unit provided in Example 1 of this application, as shown in FIG. Figure 6 As shown in the figure, the general credit service unit mainly consists of the general credit payer, sending credit instructions, blacklist scanning, sending outgoing reports, and interface NPC response SU (Service Unit). NPC generally refers to the national processing center of CNPAS2. Figure 7 This is another schematic diagram of the splitting of a common credit service unit provided in Example 1 of this application, as shown in FIG. Figure 7 As shown in the figure, the general credit business service unit mainly includes general credit beneficiary, receiving and sending credit instructions, remittance refund, transaction forwarding, blacklist scanning, receiving incoming reports, sending outgoing reports, and interface NPC response SU.

[0087] in, Figure 8 The flowchart of the real-time credit service unit splitting provided in the first embodiment of this application is as follows: Figure 8 As shown, the real-time credit business service unit mainly consists of real-time credit payer, sending credit instruction, blacklist scanning, sending outgoing report, interface NPC response SU, receiving counterparty response, receiving incoming report, and sending transaction cancellation. Figure 9 This is another schematic diagram of the splitting of the real-time credit service unit provided in Example 1 of this application, as shown in FIG. Figure 9 As shown, real-time credit mainly consists of real-time credit instructions, blacklist scanning, receiving incoming reports, responding, and sending outgoing reports.

[0088] Specifically, determine the list of candidate service units and service interfaces within the candidate service units that need to be invoked by the candidate events used by the business. Complete the code for invoking the candidate events and the candidate service units. Candidate event implementations can be reused across modules. If the same candidate event differs between modules, multiple implementations of the same candidate event can be included in the model. However, candidate event implementations are generally programmed for candidate service unit interfaces rather than for specific business logic implementations.

[0089] Furthermore, when determining the association relationship between candidate events and candidate service units, the logic of a candidate event usually needs to be completed through multiple operation interfaces on one or more candidate service units in a coordinated manner, thereby achieving logical processing of the candidate event.

[0090] Optionally, determine the service unit combination layer, including:

[0091] If the candidate event corresponds to one transaction scenario, determining an association relationship between the candidate event and the candidate service unit; wherein the transaction scenario is used to represent the scenario of the business transaction;

[0092] If there are multiple transaction scenarios corresponding to the candidate event, the association relationship between the candidate event, the transaction scenario and the candidate service unit is determined.

[0093] In this solution, after identifying candidate events and candidate service units, we need to determine the relationships between them. If a candidate event corresponds to only a single transaction scenario, then the relationships between it and the candidate service units can be determined based on the characteristics and requirements of the candidate event itself.

[0094] In this embodiment, due to differences in transaction scenarios, the corresponding candidate service units will also be different. If a candidate event corresponds to multiple transaction scenarios, it is necessary to comprehensively consider the candidate event and each transaction scenario to clarify the association between it and the candidate service unit.

[0095] For events that trigger only in a single transaction scenario, omitting the transaction scenario can simplify business processes and system design. This reduces unnecessary information processing and judgment logic, improving system efficiency and responsiveness. When an abstract event can trigger in multiple transaction scenarios, triggering it by transaction event and transaction scenario can more accurately describe and distinguish event behavior in different scenarios.

[0096] Optionally, determine the service unit combination layer, including:

[0097] When there are multiple operation interfaces corresponding to the candidate service unit, determine the association relationship between the candidate event and the interface operation corresponding to the candidate service unit; or determine the association relationship between the candidate event and the transaction scenario and the interface operation corresponding to the candidate service unit.

[0098] The operation interface refers to the abstract description of the functional interface provided by the candidate service unit to the outside during the transaction process.

[0099] In this embodiment, if a candidate service corresponds to only one operation interface, then only the association between the candidate event and the interface operation corresponding to the candidate service unit needs to be clarified. However, if a candidate service corresponds to multiple operation interfaces, then the association between the candidate event and the candidate service unit, as well as the association between the candidate event and each operation interface, must be confirmed simultaneously.

[0100] Furthermore, a candidate event in the event model layer usually completes the business processing logic corresponding to the candidate event by combining and calling at least one operation interface on one or more candidate service units. For example, the service unit includes a receiving report service unit, a blacklist scanning service unit, and a receiving credit instruction service unit. The receiving report service unit is used for incoming report parsing and signature verification; the blacklist scanning service unit is used for scanning the accounts of other banks' payees / payees and the blacklist scanning of the bank's payee / payee accounts; the receiving credit instruction service unit is used for determining the entry method and processing the entry of incoming funds. From the above, it can be seen that the receiving credit instruction service unit is a collection of its own service operations plus the service operations of the receiving report service unit and the blacklist scanning service unit.

[0101] In complex systems, multiple operational interfaces lead to diverse functional implementations for candidate service units. Determining associations allows for precise identification of interface operations that match specific candidate events. By integrating associations with transaction scenarios, the most appropriate interface operation can be selected to process transactions based on specific business scenarios and events, ensuring transactions proceed according to expected processes and minimizing errors and anomalies.

[0102] Optionally, the candidate service unit includes a sub-service unit and a composite service unit; the sub-service unit is used to abstractly describe a single business transaction processing operation;

[0103] The composite service unit is composed of at least two sub-service units;

[0104] The at least two sub-service units are in an inheritance relationship; when the at least two sub-service units are in an inheritance relationship, the output end of the previous sub-service unit is connected to the input end of the next sub-service unit; or, the at least two sub-service units are in a combination relationship.

[0105] In this solution, the sub-service unit is used to abstractly describe a single business transaction processing operation.

[0106] In this embodiment, the composite service unit is composed of at least two sub-service units. It can be composed of a combination or inheritance of sub-service units and other composite service units, or it can be formed entirely by inheritance or combination of sub-service units. The composite service unit has its own personalized abstract behavior, and part of its abstract behavior is derived from the inheritance or combination of sub-service units or other composite service units. The higher the candidate service unit is, the more it is a composite service unit formed by inheriting and combining lower-level candidate service units. The operation interface possessed by the composite service unit is a collection of the operation interface of the inherited lower-level candidate service unit and its own operation interface.

[0107] Among these sub-service units are the Send Outgoing Message Service Unit, Receive Incoming Message Service Unit, Transaction Forwarding Service Unit, and Blacklist Scanning Service Unit. Other candidate service units are composite service units. For example, the Receive Credit Instruction Service Unit is composed of other sub-service units, including the Blacklist Scanning Service Unit and the Receive Incoming Message Service Unit.

[0108] By setting up sub-service units and composite service units, the execution efficiency of candidate events is improved.

[0109] S130: The service unit operation mapping layer is connected to the operation template implementation layer to determine the association relationship between the operation interface corresponding to the candidate service unit and the candidate operation template.

[0110] In this solution, the service unit operation mapping layer in the payment settlement system architecture model is used to determine the association relationship between the operation interface corresponding to the candidate service unit and the candidate operation template.

[0111] In this embodiment, the service unit operation mapping layer is the intermediary between the candidate service unit and the candidate operation template implementation layer, and can realize the dynamic binding between the candidate service unit behavior and the candidate operation template. While maintaining the stability of the candidate service unit behavior interface, different behavior templates can be called to complete the interface function. In addition, the service unit operation mapping layer can act as a distribution layer for the operation template implementation layer. In some business scenarios, the same abstract operation may correspond to different processing branches. If the judgment of complex branch logic is placed in the operation template implementation layer, it will cause repeated program branch structures to appear repeatedly in the implementation process of different modules. This not only increases the redundancy of the code, but also greatly increases the difficulty of code maintenance.

[0112] For example, both batch payment and standard credit payers include a credit instruction sending service unit, but the actual logic of the abstract action submitted in the candidate service unit is very different. Standard credit transactions require initiation from the associated system or manual submission at the counter; batch payment transactions, on the other hand, process payment instructions sent by the payer through the collection and payment center.

[0113] The processing logic corresponding to the abstract business submission behavior in the payer's response service unit in the debit business and the abstract business submission behavior in the payee's sending debit instruction service unit in the debit business is also different, but both have a common parent service unit (sending report service unit). The former completes the processing by calling the generated response business information processing template, and the latter completes the business processing by entering the submission processing template.

[0114] In the real-time credit service, the Response Service Unit, Send Message Service Unit, and Business Information Submission processing operations are handled by the Send Message Service Unit as a subunit of the Response Service Unit. However, for standard credit services, the Send Message Service Unit is a subunit of the Send Credit Instruction Service Unit. Therefore, the business information processing templates used in the Send Message Service Unit and Business Submission processing in these two scenarios differ. This is flexibly defined by the service unit mapping layer through dynamic injection of operation templates during different business implementations. However, both services can be abstracted and reused at the service unit level.

[0115] The service unit operation mapping layer can shield the differences in abstract behaviors of different business modules or different business scenarios under the same module under the same service unit.

[0116] Specifically, two transaction management master classes PayerProcess and PayeeProcess are defined (the transaction master class of a specific module can be a subclass of these two abstract classes). The master class is responsible for registering events and managing the candidate service units used by the current payee / payee.

[0117] Furthermore, based on the specific functionality of the candidate service unit's service interface, a specific operation template class is defined, and the service unit mapping layer is written using the command pattern. If the service interface functionality is complex and requires different operation templates to be called based on different branching situations, the branch control logic must be extracted in the service unit mapping layer, allowing the service unit mapping layer to define and share the relevant logical branches of the operation template implementation layer at the abstract layer.

[0118] S140: The operation template implementation layer is used to determine a candidate operation template, where the candidate operation template is used to execute a business transaction.

[0119] In this solution, the operation template implementation layer is the most fundamental component layer in the payment and settlement system architecture model. It provides a templated definition of the implementation process of a single, reusable abstract behavior within a candidate service unit. It describes the core processing steps / links of the abstract behavior and defines the default orchestration combination of these steps / links. For example, the incoming report parsing processing template includes key operational steps such as signature verification and parsing and storage. The incoming payment processing template includes key operational steps such as obtaining incoming payment element information, determining the payment method, generating accounting elements, and performing accounting processing.

[0120] Specifically, according to specific business needs, complete the logic writing of the specific operation template class. If the implementation process of the operation template class has a certain paradigm and fixed pattern, the template design pattern can be used to define the abstract operation template, and the specific different templates can be implemented according to the actual business.

[0121] Through the above hierarchical definition, a unified model can be defined for all types of services. For example, taking the events related to the collection process of a real-time credit service as an example, the corresponding events are the two-in-one event of the payee's incoming payment confirmation and the incoming payment credit event. The service units and service operations required for this two-in-one event include: the credit instruction receiving service unit - incoming report processing operations, the response service unit - the outgoing report service unit - business information submission processing, the response service unit - the outgoing report service unit - outgoing report processing, the blacklist scanning service unit - scanning for non-bank payees (using an externally purchased sanctions list screening system and an industry-shared blacklist database for scanning, with specified formats for the sent scan information and screening results), and the blacklist scanning service unit - scanning for bank payees (using our own blacklist database). The service unit mapping layer dynamically injects the business processing template used by the current service through the command mode and forwards the operations of candidate service units to the relevant business processing templates. The business processing templates corresponding to the candidate service unit operation interface include: the incoming report parsing processing template: This template includes key operational steps such as signature verification and parsing and storage. Generate Response Business Information Processing Template: The main steps include obtaining original business information, determining the response method, and generating the response business information. Send Message Processing Template: The main steps include generating outgoing business information, generating the header, generating the message body, and sending the message. Scanning Processing Template for Non-Bank Payees / Payees: The main steps include obtaining business information to be scanned, generating the information to be scanned according to specifications, invoking the sanctions list screening system for scanning, and processing the scan results. Scanning Processing Template for Bank Payees / Payees: The main steps include obtaining account information to be scanned, scanning and comparing it with the bank's blacklist database, and processing the scan results.

[0122] This solution designs a top-down, multi-layered architecture model. By abstracting the essence of different businesses, as well as the commonalities and differences between their respective business processes and key processing steps, it begins with the premise that the essence of payment and settlement business is the flow of funds between different institutions, customers, and accounts. By defining a four-layered program architecture design model, a unified definition and description of all types of payment-related businesses in the payment and settlement system are achieved. The core layer is the event model. This layer abstractly defines the core transaction event model from two perspectives: the flow of funds between different account types and the various message interactions that drive the flow of funds during transactions. Standardized transaction scenarios are also defined based on event triggering sources. The core processing procedures of different businesses are characterized by transaction scenarios and transaction events. The specific business logic implemented by different transaction events is flexibly combined into abstract operation behaviors on one or more candidate service units. A candidate service unit is a collection of abstract descriptions of various behavior subsets of payers, payees, and senders / receivers in different transaction types, based on the perspective of business function implementation. Because the interface operations within most candidate service units share similar behaviors across different transaction implementations, they can be defined as different implementation classes of the abstract operation template class to implement specific functionality. However, in some cases, the specific functional implementations corresponding to the abstract service interfaces included in candidate service units may correspond to different template classes in different transactions, or the abstract service interfaces in the same transaction may rely on certain logical judgments to call different operation template classes in different situations. Therefore, the model also needs to introduce a service unit operation mapping layer to dynamically map the operation behaviors of candidate service units to operation templates. Through abstract refinement at different levels, such as abstract event definition, service unit classification, definition of the mapping relationship between events and service units, and definition of specific business logic template paradigms, a core transaction processing model for the payment system with a unified view is formed that is easy to understand, expand, and modify. This reduces the difficulty of developing and testing complex transaction scenarios, and further enhances the system's flexibility, scalability, robustness, and adaptability.

[0123] Furthermore, by standardizing the program architecture model for the core business of the bank's payment and settlement services, and designing a four-layer program architecture model, the common, stable, and personalized functions and behaviors of different business types in the system are extracted from top to bottom into each layer of the model in a progressive hierarchy from abstract to concrete. Differences between modules are implemented at the lowest layer of the model whenever possible, while also supporting flexible combination, assembly, and personalized expansion within each layer of the model. This allows for the rapid construction of a program implementation framework based on actual business needs and continuous iterative optimization during system evolution. This allows the core functions of each business module in the system to be more fully expressed and described in the program model. This results in a readable, easy-to-understand program architecture abstract design model with a unified view.

[0124] Through a top-down, layer-by-layer definition, description, and implementation process, from the abstract to the concrete, system modules can fully understand the system's core functions, business processes, and overall program structure without having to understand the implementation details. This layer-by-layer decomposition effectively decouples complex processes and component branching logic within the system into individual model layers, enabling precise descriptions of the business using the model's unified language. Each layer of the model has clear, well-defined boundaries and definitions. By defining this top-down program architecture model, the system's programs can be effectively made more readable and understandable.

[0125] The system is highly flexible and extensible. Each layer of the four-layer model can support flexible expansion and extension implementation, while maintaining the stability of the architectural model, it also provides expansion support for personalized processing scenarios of various businesses. For example, the event model layer and candidate service unit can support the addition of new candidate events and service units, as well as the expansion of the implementation of defined candidate events and candidate service units, and flexibly define the calling relationship between the event model layer and the service unit combination layer, and between the service unit combination layer and the operation template implementation layer. In the operation template implementation layer, multiple copies of template definitions can also be used to implement the solution to the situation where different business modules are similar at the abstract layer but different at the implementation layer.

[0126] The continuous accumulation and iteration of models can effectively improve system development efficiency. By decomposing, defining, and implementing different modules through a unified model, the model design can be continuously improved through iteration. This continuous improvement also effectively accumulates reusable model assets for the system, allowing the development paradigm and reusable business development processes of the system evolution process to be quickly applied to the development of new products and new features.

[0127] This effectively enforces regulatory constraints on the system development process. A unified development model can be used to design, define, and develop program structures for different modules. This provides strong constraints on the development paradigms for similar functions across modules, effectively standardizing development steps and processes. Existing model assets can also be fully reused. Through iterative reuse, model asset library components, as well as the calling and mapping relationships between model layers, can be continuously improved. This provides model standardization support for the rapid development of subsequent products.

[0128] The technical solution of the embodiment of the present invention defines an event model layer, a service unit combination layer, a service unit operation mapping layer, and an operation template implementation layer, and constructs a four-layer payment and settlement system architecture model based on the event model layer, the service unit combination layer, the service unit operation mapping layer, and the operation template implementation layer. By implementing this technical solution, the functions of different types of business in the system are defined, described, and implemented layer by layer from the abstract to the concrete, top to bottom. Through layer-by-layer decomposition, the complex processes and complex component branch logic in the system are effectively decomposed and decoupled into each layer of the model. The business is accurately described using the model's unified language, which can effectively improve the readability and understandability of the system's programs, thereby reducing the complexity of payment and settlement system development and improving overall development efficiency.

[0129] Example 2

[0130] Figure 10 This is a flowchart of the application of the payment and settlement system architecture model provided in the second embodiment of the present invention. The relationship between this embodiment and the above embodiment is a detailed description of the application process of the payment and settlement system architecture model. Figure 10 As shown, the method includes:

[0131] S1010. Describe the business transaction event and determine the target event;

[0132] In this solution, business transactions are triggered based on the operational behavior of the target object. By describing the business transaction process in an event-based manner, the corresponding target event is accurately matched from the preset candidate event library.

[0133] S1020: Determine a target service unit associated with the target event;

[0134] In this solution, a search is performed from the predetermined association relationship between candidate events and candidate service units to determine the target service unit associated with the target event.

[0135] Optionally, determining a target service unit associated with the target event includes:

[0136] If there is only one transaction scenario corresponding to the target event, determining a target service unit associated with the target event based on the association relationship between the candidate event and the candidate service unit;

[0137] If there are multiple transaction scenarios corresponding to the target event, the target service unit associated with the target event is determined based on the association relationship between the candidate event, the transaction scenario and the candidate service unit.

[0138] In this embodiment, when the target event corresponds to only one transaction scenario, it is only necessary to search among the predetermined association relationships between candidate events and candidate service units to determine the target service unit associated with the target event.

[0139] In this solution, when there are multiple transaction scenarios corresponding to the target event, the target service unit associated with the target event is determined based on the association relationship between the predetermined candidate events and transaction scenarios and the candidate service units.

[0140] By accurately locating the target service unit, full-process control and efficient execution of target events based on the unit can be achieved, thereby ensuring the timeliness of service response and the accuracy of execution.

[0141] Optionally, after determining the target service unit associated with the target event, the method further includes:

[0142] When there are multiple operation interfaces corresponding to the target service unit, the operation interface associated with the target service unit is determined based on the association relationship between the candidate event and the interface operation corresponding to the candidate service unit; or, the operation interface associated with the target service unit is determined based on the association relationship between the candidate event and the transaction scenario and the interface operation corresponding to the candidate service unit.

[0143] In this embodiment, if the target service unit corresponds to only a single operation interface, no additional interface determination operation is required.

[0144] In this solution, when the target service unit corresponds to multiple operation interfaces, there are two determination strategies: one can accurately locate the operation interface associated with the target service unit based on the association relationship between the candidate events and the candidate service unit interface operations; or the other can comprehensively consider the multi-dimensional association relationship between the candidate events, transaction scenarios and the candidate service unit interface operations to determine the relevant operation interface corresponding to the target service unit.

[0145] S1030: Determine a target operation template associated with the operation interface corresponding to the target service unit;

[0146] In this solution, a target operation template associated with the operation interface corresponding to the target service unit is determined based on the association relationship between the operation interface corresponding to the candidate service unit and the candidate operation template determined in advance.

[0147] S1040: Execute the target event according to the target operation template.

[0148] Furthermore, the relevant tasks of the target service unit are accurately executed according to the preset target operation template.

[0149] In this plan, Figure 11 This is a schematic diagram of the payment settlement system model application provided in Example 2 of this application, as shown in FIG. Figure 11 As shown, PayerProcess is the transaction management control class for the payer of the business being processed. It is responsible for registering events and managing the service units currently used by the payer. EventHandler is the event handler, ServiceUnit is the candidate service unit, ActionCommand is the service unit mapping processing class, and ActionTemplate is the action template implementation class. The interaction flow specifically includes: the transaction obtains the transaction management class used by the current business; for example, the payer obtains the payer transaction management control class for the current business. Based on the event name and transaction scenario, the event handler is retrieved from the set of registered events in the transaction management class to be triggered. The event handler obtains the service units used for the current event through the transaction management class and calls the operation interfaces on each service unit. The service unit operation interfaces are distributed through the service unit mapping layer, calling the corresponding action template implementation class to complete the business processing logic and return. Event processing completes the call and returns.

[0150] The technical solution of the embodiment of the present invention determines the target event by describing the business transaction event; determines the target service unit associated with the target event; determines the target operation template associated with the operation interface corresponding to the target service unit; and executes the target event according to the target operation template. By implementing this technical solution, the functions of different types of business in the system are defined, described, and implemented layer by layer from the abstract to the concrete, from top to bottom. Through layer-by-layer decomposition, the complex processes and complex component branch logic in the system are effectively decomposed and decoupled into the various layers of the model. The business is accurately described using the model's unified language, which can effectively improve the efficiency of business transaction processing.

[0151] Example 3

[0152] Figure 12 Schematic diagram of the structure of the payment settlement system architecture model construction device provided by the third embodiment of the present invention. Figure 12 As shown, the device includes:

[0153] An event model layer determination module 1210 is configured to determine an event model layer; the event model layer is connected to the service unit combination layer and is configured to determine candidate events required for a business transaction, wherein the candidate events are used to abstractly describe the business transaction;

[0154] A service unit combination layer determination module 1220 is configured to determine a service unit combination layer; the service unit combination layer is connected to the service unit operation mapping layer and is configured to determine candidate service units, wherein the candidate service units are used to abstractly describe business transaction processing operations;

[0155] The service unit operation mapping layer determination module 1230 is used to determine the service unit operation mapping layer; the service unit operation mapping layer is connected to the operation template implementation layer and is used to determine the association relationship between the operation interface corresponding to the candidate service unit and the candidate operation template;

[0156] The operation template implementation layer determination module 1240 is used to determine the operation template implementation layer; the operation template implementation layer is used to determine candidate operation templates, and the candidate operation templates are used to execute business transactions.

[0157] Optionally, determining a service unit combination layer 1220 is specifically used to:

[0158] If the candidate event corresponds to one transaction scenario, determining an association relationship between the candidate event and the candidate service unit; wherein the transaction scenario is used to represent the scenario of the business transaction;

[0159] If there are multiple transaction scenarios corresponding to the candidate event, the association relationship between the candidate event, the transaction scenario and the candidate service unit is determined.

[0160] Optionally, determining the service unit combination layer 1220 is further used to:

[0161] When there are multiple operation interfaces corresponding to the candidate service unit, determine the association relationship between the candidate event and the interface operation corresponding to the candidate service unit; or determine the association relationship between the candidate event and the transaction scenario and the interface operation corresponding to the candidate service unit.

[0162] Optionally, the candidate service unit includes a sub-service unit and a composite service unit; the sub-service unit is used to abstractly describe a single business transaction processing operation;

[0163] The composite service unit is composed of at least two sub-service units;

[0164] The at least two sub-service units are in an inheritance relationship; when the at least two sub-service units are in an inheritance relationship, the output end of the previous sub-service unit is connected to the input end of the next sub-service unit; or, the at least two sub-service units are in a combination relationship.

[0165] Optionally, the device further includes:

[0166] The target event determination module is used to describe business transactions and determine target events;

[0167] a target service unit determination module, configured to determine a target service unit associated with the target event;

[0168] a target operation template determining module, configured to determine a target operation template associated with an operation interface corresponding to the target service unit;

[0169] The target event execution module is used to execute the target event according to the target operation template.

[0170] Optionally, the target service unit determination module is specifically used to:

[0171] If there is only one transaction scenario corresponding to the target event, determining a target service unit associated with the target event based on the association relationship between the candidate event and the candidate service unit;

[0172] If there are multiple transaction scenarios corresponding to the target event, the target service unit associated with the target event is determined based on the association relationship between the candidate event, the transaction scenario and the candidate service unit.

[0173] Optionally, the device further includes:

[0174] An operation interface determination module is used to determine the operation interface associated with the target service unit based on the association relationship between the candidate event and the interface operation corresponding to the candidate service unit when there are multiple operation interfaces corresponding to the target service unit; or to determine the operation interface associated with the target service unit based on the association relationship between the candidate event and the transaction scenario and the interface operation corresponding to the candidate service unit.

[0175] The payment settlement system architecture model construction device provided in an embodiment of the present invention can execute the payment settlement system architecture model construction method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0176] Example 4

[0177] Figure 13 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0178] like Figure 13As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. Various programs and data required for the operation of the electronic device 10 can also be stored in the RAM 13. The processor 11, ROM 12, and RAM 13 are connected to each other via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0179] Multiple components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0180] The processor 11 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors that run machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as the method for constructing a payment and settlement system architecture model.

[0181] In some embodiments, the payment settlement system architecture model construction method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the payment settlement system architecture model construction method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the payment settlement system architecture model construction method in any other appropriate manner (for example, by means of firmware).

[0182] Various embodiments of the systems and techniques described above can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0183] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0184] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0185] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0186] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0187] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0188] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0189] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A method for constructing a payment and settlement system architecture model, characterized in that: The method comprises: Determine an event model layer; the event model layer is connected to the service unit combination layer and is used to determine candidate events required for business transactions, and the candidate events are used to abstractly describe business transactions; Determining a service unit combination layer; the service unit combination layer is connected to the service unit operation mapping layer and is used to determine candidate service units, wherein the candidate service units are used to abstractly describe business transaction processing operations; Determine a service unit operation mapping layer; the service unit operation mapping layer is connected to the operation template implementation layer and is used to determine the association relationship between the operation interface corresponding to the candidate service unit and the candidate operation template; Determine an operation template implementation layer; the operation template implementation layer is used to determine candidate operation templates, and the candidate operation templates are used to execute business transactions.

2. The method according to claim 1, characterized in that Determine the service unit composition layer, including: If the candidate event corresponds to one transaction scenario, determining an association relationship between the candidate event and the candidate service unit; wherein the transaction scenario is used to represent the scenario of the business transaction; If there are multiple transaction scenarios corresponding to the candidate event, the association relationship between the candidate event, the transaction scenario and the candidate service unit is determined.

3. The method according to claim 1, characterized in that Determine the service unit composition layer, including: When there are multiple operation interfaces corresponding to the candidate service unit, determine the association relationship between the candidate event and the interface operation corresponding to the candidate service unit; or determine the association relationship between the candidate event and the transaction scenario and the interface operation corresponding to the candidate service unit.

4. The method according to claim 1, wherein The candidate service unit includes a sub-service unit and a composite service unit; the sub-service unit is used to abstractly describe a single business transaction processing operation; The composite service unit is composed of at least two sub-service units; The at least two sub-service units are in an inheritance relationship; when the at least two sub-service units are in an inheritance relationship, the output end of the previous sub-service unit is connected to the input end of the next sub-service unit; or, the at least two sub-service units are in a combination relationship.

5. The method according to any one of claims 1 to 4, characterized in that The application process of the payment and settlement system architecture model includes: Describe business transactions and identify target events; determining a target service unit associated with the target event; Determining a target operation template associated with an operation interface corresponding to the target service unit; The target event is executed according to the target operation template.

6. The method according to claim 5, characterized in that Determining a target service unit associated with the target event includes: If there is only one transaction scenario corresponding to the target event, determining a target service unit associated with the target event based on the association relationship between the candidate event and the candidate service unit; If there are multiple transaction scenarios corresponding to the target event, the target service unit associated with the target event is determined based on the association relationship between the candidate event, the transaction scenario and the candidate service unit.

7. The method according to claim 5, characterized in that After determining the target service unit associated with the target event, the method further includes: When there are multiple operation interfaces corresponding to the target service unit, the operation interface associated with the target service unit is determined based on the association relationship between the candidate event and the interface operation corresponding to the candidate service unit; or, the operation interface associated with the target service unit is determined based on the association relationship between the candidate event and the transaction scenario and the interface operation corresponding to the candidate service unit.

8. A device for constructing a payment and settlement system architecture model, characterized in that: The device comprises: An event model layer determination module, configured to determine an event model layer; the event model layer is connected to the service unit combination layer and configured to determine candidate events required for a business transaction, wherein the candidate events are used to abstractly describe the business transaction; a service unit combination layer determination module, configured to determine a service unit combination layer; the service unit combination layer being connected to the service unit operation mapping layer and configured to determine candidate service units, the candidate service units being configured to abstractly describe business transaction processing operations; A service unit operation mapping layer determination module is used to determine a service unit operation mapping layer; the service unit operation mapping layer is connected to the operation template implementation layer and is used to determine the association relationship between the operation interface corresponding to the candidate service unit and the candidate operation template; The operation template implementation layer determination module is used to determine the operation template implementation layer; the operation template implementation layer is used to determine candidate operation templates, and the candidate operation templates are used to execute business transactions.

9. An electronic device, characterized in that: The electronic device comprises: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the payment settlement system architecture model construction method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the payment settlement system architecture model construction method according to any one of claims 1 to 7 when executed.

Images