Flexible configurable transaction refund processing method and system

Abstract

The application discloses a flexible configurable transaction refund processing method and system, and relates to the technical field of financial processing, wherein the method comprises the following steps: when a first financial institution identifies that a current transaction is a transaction to be refunded, the first financial institution sends a cancellation message to a second financial institution for the current transaction; the second financial institution determines a transaction refund processing strategy corresponding to a business requirement scenario of the current transaction according to the business requirement scenario of the current transaction and a pre-configured relationship between the business requirement scenario and the transaction refund processing strategy, and sends a refund message to the first financial institution according to the transaction refund processing strategy. The application can flexibly cope with the needs of cancellation and refund raised by each financial institution, and can realize various changes of the cancellation and refund business scenarios without modifying system codes, thereby not only expanding the system functions, but also improving the flexible configurability of the system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of financial processing, in particular to a flexible configurable transaction refund processing method and system. BACKGROUND

[0002] This section is intended to provide background or context to the embodiments of the application recited in the claims. The description herein does not constitute admission of prior art.

[0003] At present, the processing of the cancellation and refund business in the payment clearing field of the financial industry is usually in the form of developing codes, and the processing logic of the cancellation and refund business is directly written. If the business requirements change and the cancellation and refund scenarios change, in order to add new logic, it is possible to modify the codes, which has a long construction period and is not flexible. SUMMARY

[0004] The embodiments of the present application provide a flexible configurable transaction refund processing method, which is used to flexibly cope with the cancellation and refund requirements of each financial institution, and various changes of the cancellation and refund business scenarios can be realized without modifying the system codes, the system functions are expanded, and the flexibility and configurability of the system are improved. The method comprises:

[0005] The first financial institution sends a cancellation message to the second financial institution for the current transaction when it identifies that the current transaction is a transaction to be refunded.

[0006] The second financial institution determines the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction according to the relationship between the business requirement scenario of the current transaction and the pre-configured relationship between the business requirement scenario and the transaction refund processing strategy, and sends a refund message to the first financial institution according to the transaction refund processing strategy.

[0007] The embodiments of the present application also provide a flexible configurable transaction refund processing system, which is used to flexibly cope with the cancellation and refund requirements of each financial institution, and various changes of the cancellation and refund business scenarios can be realized without modifying the system codes, the system functions are expanded, and the flexibility and configurability of the system are improved. The system comprises:

[0008] The first financial institution is configured to send a cancellation message to the second financial institution for the current transaction when it identifies that the current transaction is a transaction to be refunded.

[0009] The second financial institution is configured to determine the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction according to the relationship between the business requirement scenario of the current transaction and the pre-configured relationship between the business requirement scenario and the transaction refund processing strategy, and send a refund message to the first financial institution according to the transaction refund processing strategy.

[0010] The embodiment of the present application further provides a computer device, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the flexible configurable transaction refund processing method when executing the computer program.

[0011] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program implements the flexible configurable transaction refund processing method when executed by a processor.

[0012] The embodiment of the present application further provides a computer program product, which comprises a computer program, and the computer program implements the flexible configurable transaction refund processing method when executed by a processor.

[0013] In the embodiment of the present application, the flexible configurable transaction refund processing scheme comprises the following steps: when the first financial institution identifies that the current transaction is a transaction to be refunded, the first financial institution sends a cancellation message to the second financial institution for the current transaction; the second financial institution determines the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction according to the business requirement scenario of the current transaction and the relationship between the business requirement scenario and the transaction refund processing strategy pre-configured, and sends a refund message to the first financial institution according to the transaction refund processing strategy. The present application can flexibly cope with the demand for cancellation and refund raised by branches, and can realize various changes of the cancellation and refund business scenario without modifying the system code, thereby not only expanding the system function, but also improving the flexible configurability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor. In the drawings:

[0015] Figure 1 The flowchart of the processing and operation of the received refund electricity in the embodiment of the present application is shown in the figure;

[0016] Figure 2 The figure shows the processing and operation of the received refund electricity in the embodiment of the present application;

[0017] Figure 3 The figure shows the processing and operation of the received refund electricity in the embodiment of the present application;

[0018] Figure 4 The figure shows the processing and operation of the received refund electricity in the embodiment of the present application;

[0019] Figure 5 The figure is a structural schematic diagram of the transaction refund processing system which is flexibly configurable in the embodiment of the present application. DETAILED DESCRIPTION

[0020] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the embodiments of the present application are further described in detail below with reference to the drawings. Herein, the illustrative embodiments of the present application and the descriptions thereof are used to explain the present application but not to limit the present application.

[0021] The acquisition, storage, use, processing and the like of data in the technical solutions of the present application all comply with the relevant provisions of the national laws and regulations.

[0022] The term "and / or" herein merely describes an association relationship and means that three relationships can exist, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone. In addition, the term "at least one" herein means any one of multiple or any combination of at least two of multiple, for example, including at least one of A, B and C can mean including any one or more elements selected from the set consisting of A, B and C.

[0023] In the description of the present specification, "comprise", "include", "have", "contain" and the like are all open terms, that is, mean to include but not limited to. The description of the terms "one embodiment", "one specific embodiment", "some embodiments", "for example" and the like means that the specific features, structures or characteristics described in combination with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily mean the same embodiment or example. Moreover, the specific features, structures or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. The order of the steps involved in the embodiments is used to illustrate the implementation of the present application, and the order of the steps is not limited, and can be appropriately adjusted as needed.

[0024] The payment clearing system is a very important part of the bank IT system, and most of the bank business needs to rely on the payment clearing system. GUPP (Global Unified Payment Platform) provides payment clearing services for all overseas branches of the Bank of China, and GUPP adopts a global logic centralized and unified deployment manner to fully exert the advantages of internal messages, further improve the payment clearing efficiency and reduce the operation cost.

[0025] The revocation refers to that a financial institution sends MT192 / MT292 message to another financial institution as a revocation request, requesting the latter to revoke the original message specified in the MT192 / MT292 message. The stop payment refers to the cancel processing in the GUPP, and the process includes canceling the message of the uncompleted account processing, and the stop payment is irrelevant to the account processing which has been completely processed. The refund refers to that the bank receives the revocation message, and decides to refund the headroom to the applicant bank after the revocation; or due to some reasons, the bank cannot correctly process the message, and sends the refund message to the opposite bank.

[0026] At present, the revocation and refund business processing in the payment and clearing field of the financial industry is usually in the form of development code, and the processing logic of the revocation and refund business is directly written. If the business scene changes, the code needs to be modified, which makes the system function not flexible. The method of using the code to determine the business logic is not flexible. That is, if the business demand changes and the revocation and refund scene changes, in order to increase the new logic, it is possible to modify the code, and the construction period is long and not flexible.

[0027] In order to support processing various complex revocation and refund scenes in the bank payment and clearing field, the embodiment of the present application provides a flexible and configurable transaction refund processing scheme, that is, the GUPP application provides a configurable processing mechanism suitable for such business, and the business demand scene is as follows:

[0028] 1) Revocation and refund processing of SWIFT, SWIFTFinCopy, and local clearing proprietary format payment message;

[0029] 2) Refund processing of Pacs008 and Pacs003 messages of G3BULK import and export transactions;

[0030] 3) Refund message of message type Pacs004, MT103, MT202, CHIPS and FED;

[0031] 4) For the original report, the refund message associated with the original report is generated by clicking the Return button.

[0032] The above scene "1)" is the business demand scene of the SWIFT specification format, and scenes "2)-4)" are the business demand scenes of the non-SWIFT specification format.

[0033] The revocation processing refers to that a financial institution sends MT192 / MT292 message to another financial institution as a revocation request, requesting the latter to revoke the original message specified in the MT192 / MT292 message.

[0034] According to the difference of the active initiator in the revocation process, the revocation processing is divided into two cases of receiving revocation message and sending revocation message, wherein the case of receiving revocation message is further divided into the cases of receiving revocation message in the in-flow business scenario and receiving revocation message in the transfer scenario according to the difference of the business scenario.

[0035] Revocation:

[0036] For the receiving MT192 / MT292 scenario: from receiving MT192 / MT292 from the system to sending MTn96 (rejecting revocation) or GUPP system deciding to return the operation, the whole process is the revocation process.

[0037] For the sending MT192 / MT292 scenario: from sending MT192 / MT292 message from the system to receiving the feedback message sent by the receiving bank, the whole process is called the revocation process.

[0038] Stop payment:

[0039] The stop payment process refers to the account level, that is, the cancel processing in GUPP, and the process includes canceling the stop payment of the uncompleted account processing message, and if the account has been completely processed, it is irrelevant to the stop payment.

[0040] Return:

[0041] After receiving the revocation message, it is decided to return the position to the applicant bank; or due to some reasons, the bank cannot correctly process the message, and will send a return message to the opposite party.

[0042] According to the definition of project scope and product function, the business scope supported by GUPP is limited to the revocation and return processing of SWIFT, SWIFT Fin Copy, and local clearing proprietary format payment messages processed by GUPP, and GUPP also supports the return processing of Pacs008 and Pacs003 messages of G3BULK in-flow and out-flow transactions. The return message types supported by GUPP include: Pacs004, MT103, MT202, CHIPS, FED return message. GUPP does not support the automatic processing of receiving return messages in the case of receiving double electricity for the original message but sending single electricity.

[0043] In the scenario of receiving revocation message and sending return message in the bank, the system supports matching the received MT192 / MT292 with the original report, and generating a standard SWIFT return message associated with the original report by clicking the Return button for the original report.

[0044] To sum up, in the embodiment of the present application: 1. The code developer needs to separate each business scenario of withdrawal and refund, and make it into a small component, so as to facilitate subsequent configuration and development of the developer. 2. The configuration developer needs to configure the rules of withdrawal and refund, and more conveniently realize different needs of branches. The design and development of the rules need to be clarified with the business for several rounds. The flexible and configurable transaction refund processing scheme will be described in detail below.

[0045] Figure 4 The flowchart of the flexible and configurable transaction refund processing method in the embodiment of the present application is shown in FIG. 1, and the method comprises the following steps: Figure 4

[0046] Step 101: When the first financial institution identifies that the current transaction is a transaction to be refunded, the first financial institution sends a withdrawal message to the second financial institution for the current transaction.

[0047] Step 102: The second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and sends a refund message to the first financial institution according to the transaction refund processing strategy.

[0048] The flexible and configurable transaction refund processing method provided by the embodiment of the present application works as follows: when the first financial institution identifies that the current transaction is a transaction to be refunded, the first financial institution sends a withdrawal message to the second financial institution for the current transaction; the second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and sends a refund message to the first financial institution according to the transaction refund processing strategy. The present application can flexibly cope with the needs of withdrawal and refund proposed by branches, and various changes of withdrawal and refund business scenarios can be realized without modifying the system code, thereby not only expanding the system function, but also improving the flexible configurability of the system. The flexible and configurable transaction refund processing method will be described in detail below.

[0049] In one embodiment, the second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and sends a refund message to the first financial institution according to the transaction refund processing strategy, comprising:

[0050] ​The second financial institution determines, according to the current transaction business requirement scenario and the pre-configured relationship between the business requirement scenario and the transaction refund processing strategy, that the transaction refund processing strategy corresponding to the current transaction business requirement scenario is: a SWIFT, SWIFTFinCopy, or local clearing proprietary format payment message revocation and refund processing strategy, and sends a refund message to the first financial institution according to the transaction refund processing strategy.

[0051] In a specific implementation, for the above "1)", the refund message is sent to the first financial institution according to the SWIFT, SWIFTFinCopy, or local clearing proprietary format payment message revocation and refund processing strategy, further improving the system flexibility and configurability.

[0052] In an embodiment, the SWIFT, SWIFTFinCopy, or local clearing proprietary format payment message revocation and refund processing strategy includes:

[0053] The refund message is automatically matched with the original message;

[0054] The refund message that fails in automatic matching is put into an ROFi queue, and original messages that meet preset manual matching rules are screened out for manual selection and matching by business personnel;

[0055] If both automatic matching and manual matching fail, a message that needs to be processed is found from the refund message queue;

[0056] When processing the received refund message in the automatic processing and forwarding scenario, the message field is determined and sent to the original message sender.

[0057] In a specific implementation, the above SWIFT, SWIFTFinCopy, or local clearing proprietary format payment message revocation and refund processing strategy further improves the system flexibility and configurability.

[0058] In an embodiment, the second financial institution determines, according to the current transaction business requirement scenario and the pre-configured relationship between the business requirement scenario and the transaction refund processing strategy, that the transaction refund processing strategy corresponding to the current transaction business requirement scenario, and sends a refund message to the first financial institution according to the transaction refund processing strategy, including:

[0059] The second financial institution determines, according to the current transaction business requirement scenario and the pre-configured relationship between the business requirement scenario and the transaction refund processing strategy, that the transaction refund processing strategy corresponding to the current transaction business requirement scenario is: a Pacs008 or Pacs003 message refund processing strategy for G3BULK import and export transactions, and sends a refund message to the first financial institution according to the refund processing strategy.

[0060] Or, the second financial institution determines the business demand scenario corresponding to the transaction return processing strategy according to the current transaction business demand scenario and the relationship between the pre-configured business demand scenario and the transaction return processing strategy, which is: according to the message type Pacs004, MT103, MT202, CHIPS, FED return message strategy, the return message is sent to the first financial institution;

[0061] Or, the second financial institution determines the business demand scenario corresponding to the transaction return processing strategy according to the current transaction business demand scenario and the relationship between the pre-configured business demand scenario and the transaction return processing strategy, which is: according to the message type Pacs004, MT103, MT202, CHIPS, FED return message strategy, the return message is sent to the first financial institution;

[0062] In specific implementation, for the above-mentioned "2)-4)" non-SWIFT specification format business demand scenario, according to the Pacs008, Pacs003 message return processing strategy of G3BULK import and export transaction, the message type is Pacs004, MT103, MT202, CHIPS, FED return message strategy, the original payment message is matched from the cancellation message, and the return message associated with the original payment message is generated according to the strategy of the original payment message, and the return message is sent to the first financial institution, which further improves the system flexibility.

[0063] In one embodiment, the Pacs008, Pacs003 message return processing strategy of G3BULK import and export transaction, or the message type is Pacs004, MT103, MT202, CHIPS, FED return message strategy, or the original payment message is matched from the cancellation message, and the return message associated with the original payment message is generated according to the strategy of the original payment message, which includes:

[0064] The return message and the original message are automatically matched according to the preset rule;

[0065] After automatic matching is successful, the return message needs to link the original message, and the AFTER message 21 field of the return message is equal to the original 20 field of the original message;

[0066] If it is a transfer, the receiving line of the return message should be equal to the first valid debit of the original message, and the After message meets the preset mapping rule;

[0067] If automatic matching and manual matching both fail, find the message to be processed from the return message queue;

[0068] If Pacs009 non-standard return message with INTERO as the debit MOP is received from the online line, this type of message is not supported to enter the return process for processing, and manual processing is required for this type of message.

[0069] In specific implementation, the return processing strategy of the Pacs008 and Pacs003 messages of the G3BULK import and export transaction, or the return message strategy of the message types of Pacs004, MT103, MT202, CHIPS, and FED, or the detailed implementation of the strategy of matching the original payment message from the cancellation message and generating the return message associated with the original payment message for the original payment message further improves the flexibility of the system.

[0070] In order to facilitate understanding of how the present application is implemented, the following will be described in detail in combination with Figures 1 to 3 .

[0071] I. Initiating a cancellation instruction

[0072] 1. GUPP initiates MT192 / MT292 (in the export scenario)

[0073] GUPP cannot directly initiate MT192 / MT292 cancellation instructions. The implementation is as follows: For the export message that needs to be cancelled, click Query to initiate a query, and write in the query information that it needs to be cancelled. The system generates MTn95 and transmits it to IARS. IARS receives the query and sends MT192 / MT292 to the opposite party according to the cancellation request, thereby realizing the function of sending a cancellation instruction from GUPP.

[0074] 2. The opposite party responds to the cancellation instruction sent by our bank

[0075] The opposite party (for example, the first financial institution, which can be a branch) receives MT192 / MT292 sent by our bank (for example, the second financial institution, GUPP (Global Unified Payment Platform)) and will send different replies to our bank according to different business scenarios (the four business requirement scenarios mentioned above).

[0076] (1) The opposite party cancels the original message according to the cancellation instruction (in the case of having been debited), and sends a return message (MT103 / MT202) to our bank.

[0077] GUPP receives the return message and the detailed processing is described in the "Received Return" section below.

[0078] (2) The opposite party replies to our bank with MTn96 / MTn99 messages in response to the cancellation instruction (in the case of not having been debited).

[0079] The opposite party replies to our bank with MTn96 messages, which may exist in the following scenarios:

[0080] (1) For some reasons, the counterparty bank cannot do the cancellation on the original message.

[0081] (2) The original message has not been processed, and the counterparty bank informs us of the cancellation success.

[0082] For the scenario of receiving the MTn96 message, the business staff performs the corresponding operation according to the instruction.

[0083] II. Receiving the refund

[0084] After receiving the cancellation instruction initiated by our bank, the counterparty bank sends the refund message to our bank.

[0085] There are also some scenarios in which our bank does not actively initiate the cancellation instruction, and the counterparty bank initiates the refund to our bank due to some reasons (e.g., the original message is incorrect, and the counterparty bank cannot make the entry).

[0086] Regardless of whether our bank requires cancellation or the counterparty bank initiates the refund, the processing and operation of the GUPP system after receiving the refund message follow the same process as shown in Figure 1 .

[0087] 1. The receiving bank of the original payment message sends the refund position message to the GUPP.

[0088] 2. The message containing any one of 'RETURN', 'REFUND', 'REJECT', 'RETN', 'REJT', 'RTN' in field 72 (when the message type is MT202, field 58 = the office) will enter the special processing flow of the refund message, and the subsequent matching processing with the original message is shown in 3. Otherwise, the message that does not meet the above conditions will not enter the processing flow of the refund message.

[0089] 3. The message entering the special processing flow of the refund message will be matched with the original message.

[0090] I. Determine whether the refund message type is a refund message in the format conforming to the SWIFT specification:

[0091] The message type is MT103, MT202, MT202COV, or MT205;

[0092] The first line in field 72 contains the code word: / RETN / or / REJT / ;

[0093] The third line in field 72 contains the code word: / MREF / ;

[0094] The debit MOP is not equal to BOOK, and the credit MOP is not empty.

[0095] If the conditions of scenario I (SWIFT specification format scenario) are met, the process is handled according to the following described flow, otherwise, the judgment process is carried out according to flow II.

[0096] (1) The return report is first automatically matched with the original report, and the matching rules are as follows:

[0097] The sending line of the return report is equal to the receiving line of the original report.

[0098] The state of the original report is not REJECTED or RETURNED.

[0099] The type of the original report is MT103, MT202, MT202COV, MT205.

[0100] The first line of field 72 of the return report contains the code word: / RETN / or / REJT / .

[0101] The content under the / MREF / keyword in field 72 of the return report is equal to the 20 field (Instr ID) of the original report.

[0102] (2) The return report that fails automatic matching will enter the ROFi queue, and the system will automatically select the original report that meets the following manual matching rules for business personnel to manually select and match:

[0103] The original report is a PAY message;

[0104] The original report and the return report are both MT103, MT202, MT202COV, MT205;

[0105] The first line of field 72 of the return report does not contain / RETN / or / REJT / ;

[0106] The state of the original report is COMPLETE;

[0107] The amount in field 32 of the return report is within the difference tolerance range (set by the system parameter RJCT_TOLERANCE_PRCNT);

[0108] The value date of the return report is within three days of the value date of the original report.

[0109] (3) If both automatic and manual matching fail, the teller finds the message to be processed from the return message queue. If it is a SWIFT message, the information after the 72 field / MREF / of the return message (the original message 20 field) can be used to manually add the MID of the return message in the Notes of the original message to mark the association. At the same time, cancel the original message and cancel the return message. If the original message is an outgoing message, the account adjustment needs to be manually performed in the core system. If the original message is a remittance message, a new return message is created in the GUPP system, and the 72 field contains the return identification. The system will process the newly created return transaction according to the HighValue Workflow of sending the return message.

[0110] (4) When GUPP automatically processes the return message received in the remittance scenario, the message fields sent to the original message sender are as follows:

[0111] Return message F20 = GUPP newly generated F20;

[0112] Return message F21 = F21 received from the original message;

[0113] Return message F50 = F50 received from the original message;

[0114] Return message F57 = F57 received from the original message;

[0115] Return message F58 = F58 received from the original message;

[0116] Return message F59 = F59 received from the original message;

[0117] Return message F72 / MREF / number after = F20 received from the original message.

[0118] II. If the return message is not in the SWIFT specification format (i.e., the business scenario II is a business requirement scenario in a non-SWIFT specification format), determine whether the return message meets the following conditions:

[0119] Message type is MT202.

[0120] 72 field contains any of 'RETURN', 'REFUND', 'REJECT', 'RETN', 'REJT', 'RTN'.

[0121] 58 field = this office.

[0122] If yes, process according to the following description, otherwise, proceed with the subsequent processing:

[0123] (1) The withdrawal report and the original report are automatically matched according to the following rules:

[0124] The withdrawal report sending line = the AFTER report receiving line of the original report;

[0125] The withdrawal report 21 field = the 20 field of the original report;

[0126] The withdrawal report 32 field currency = the original report 32 field currency.

[0127] (2) After automatic matching is successful, the withdrawal report needs to link the original report, and the AFTER report 21 field of the withdrawal report = the original 20 field of the original report.

[0128] The withdrawal report that fails automatic matching will enter the ROFi queue, and the system will automatically select the original report that meets the following manual matching rules for business personnel to manually select and match:

[0129] The original report is a PAY message;

[0130] Both the original report and the withdrawal report are MT103, MT202, MT202COV, or MT205;

[0131] The original report 72 field does not contain any of 'RETN', 'REJT', 'REFUND', 'RETURN', 'REJECT', or 'RTN';

[0132] The original report status is COMPLETE;

[0133] The withdrawal report 32 field amount is within the tolerance range (set by the system parameter RJCT_TOLERANCE_PRCNT).

[0134] (3) In this scenario, if it is a transfer, the withdrawal report receiving line should equal the first valid debit of the original report, and the AFTER report mapping rules are:

[0135] The AFTER report receiving line = the first valid debit of the original report;

[0136] The AFTER report 21 field = the original 20 field of the original report;

[0137] The AFTER report 32 field value date, amount, and currency equal the manually modified values;

[0138] After message 58 field = first valid debit field of original message;

[0139] After message 72 field = 72 field of received before message. (In case of manual modification, equal to modified value).

[0140] (4) If automatic matching fails, the teller finds the message to be processed from the return message queue. If it is a SWIFT message, the teller manually adds the MID of the return message in the Notes of the original message to mark the association. Meanwhile, the original message is cancelled and the return message is cancelled. If the original message is an outgoing message, the teller needs to manually make account adjustment in the core system. If the original message is a transfer message, the teller needs to create a new return message in the GUPP system, with the return identifier in the 72 field. The system will process the new return transaction according to the High Value Workflow of sending the return message.

[0141] (5) If a Pacs009 non-standard return message (the receiving bank and 58 field equal to the office, and the 72 field contains a return identifier) with INTERO as the debit MOP is received from the online bank, the GUPP does not support this type of message entering the return process. For this type of message, manual processing is required, as described in (4).

[0142] 4. In the above scenario II (non-standard return scenario), for a certain branch, if the original message is a FED / CHIPSto SWIFT transfer scenario, after receiving the return message from SWIFT, automatic transfer to FED / CHIPS is not supported. The processing flow of receiving a SWIFT non-standard return message is as follows:

[0143] (1) Automatic matching is performed according to steps (1) and (2) in scenario II.

[0144] (2) If automatic matching fails, the return message enters the ROFI queue, and manual matching is performed according to steps (2) in scenario II.

[0145] (3) After successful matching, the original message and the return message are associated with each other, and the original message enters the WAITRETURN state.

[0146] (4) The teller manually modifies the account number in the 58 field of the return message to the transition account, processes the return message to the COMPLETE state, and places the returned position in the office account. At this time, the status of the original message changes to RETURNED.

[0147] (5) Manually create a FED / CHIPS return message or a normal FED / CHIPS outgoing message, and select the debit account as the credit account of the return message, i.e. the transition account, and select the credit account as the sender of the original FED / CHIPS message, so as to return the position to the original sender through FED / CHIPS.

[0148] 5. In the above scenarios I. and scenario II., the return message of the original report is automatically or manually matched and placed in the return queue, and the return amount, interest date, and 72 field can be manually modified.

[0149] This requirement follows the implementation mode of Asia-Pacific, Europe and Africa, and is realized through customer queue and special instruction. If the 72 field of the message contains any of the identifiers 'RETN', 'REJT', 'REFUND', 'RETURN', 'REJECT', 'RTN', the message falls into the customer queue 'RETN REJT RFND', and the message hits the special instruction. The message status is changed to Repair, and the return amount, interest date, and 72 field information can be manually modified.

[0150] The credit account of the original message is selected as the debit account of the return message, the debit account of the original message is selected as the credit account of the return message, and the debit MOP of the original message is selected as the credit MOP of the return message. The debit and credit accounts of GUPP are skipped, and subsequent exchange rate conversion, fees, special instructions, etc. are processed.

[0151] The status of the original message associated with the return message will be changed to WAITREJECT or WAITRETURN. When the return message processing is completed and the status of the return message becomes COMPLELE, the status of the original message will be changed to REJECTED or RETURNED accordingly.

[0152] 6. In the above scenarios I. and scenario II., for other branches, the original message is in the transfer scenario, and if the received return message is successfully matched with the original message according to the automatic matching rule or the manual matching rule, the After message type of the return message is MT202 regardless of the type of the original message; if the debit MOP of the original message is CHATS, the After message type of the return message is consistent with the type of the original message.

[0153] 7. According to the current processing status of the original message, mainly the accounting status, i.e. according to the debit account of the original message, the credit account of the return message is determined, and the return message is processed as follows.

[0154] In the scenario of original message collection, if the debit side of GUPP original message processing is the intermediate account, not the 50th account of the message, the business personnel need to manually complete the account processing between the 50th account and the intermediate account. After GUPP completes the return flow process, manual account adjustment is needed in the core: debit: cross-system account 8321, credit: real debit account of the channel.

[0155] (1) The system identifies the return message, but both automatic matching and manual matching fail, and the original message needs to be canceled, and the return message needs to be canceled:

[0156] 1) If the original message is a remittance message, manually adjust the account in the core, and the posting entry is as follows:

[0157] Dr: original message credit account;

[0158] Cr: 8321;

[0159] Dr: 8321;

[0160] Cr: original message debit account.

[0161] 2) If the original message is a transfer message, send a return message in GUPP, the message 72th contains a return identifier, the debit account is the original message credit account, and the credit account is the original message debit account.

[0162] Dr: original message credit account;

[0163] Cr: 8321;

[0164] Dr: 8321;

[0165] Cr: original message debit account.

[0166] (2) The system identifies the return message and the matching is successful

[0167] 1) The system automatically matches the return message with the original message, and after the return message processing is completed, the return message status becomes Complete, and the original message status becomes RETURNED / REJECTED. The corresponding posting entry should be:

[0168] Dr: original message credit account;

[0169] Cr: 8341;

[0170] Dr: 8341;

[0171] Cr: original message debit account.

[0172] 8. GUPP initiates a return report, if the debit account is a customer account, Account Lookup is required, and the message filtering conditions are as follows:

[0173] Debit MOP is BOOK;

[0174] When the message type is MT103 / 202, if the 72 field contains the words "RETURN", "REFUND", "REJECT", "RETN", "REJT", 'RTN', do Account Lookup processing.

[0175] GUPP received return report, if the credit account is a customer account, Account Lookup is required. The message filtering conditions are as follows:

[0176] Credit MOP is BOOK;

[0177] When the message type is MT103 / 202, if the 72 field contains the words "RETURN", "REFUND", "REJECT", "RETN", "REJT", 'RTN', do Account Lookup processing.

[0178] 9. When the original message scenario is to receive double telegram message and send single telegram message, GUPP does not support automatic processing of received return report. When receiving a return report, the message will fall into the manual processing queue, and subsequent operations need to be completed manually.

[0179] III. Receiving the other party's cancellation instruction and stop payment

[0180] In specific implementation, as shown in Figure 2 :

[0181] 1. Receiving cancellation or voluntary stop payment:

[0182] i) Receiving the other party's cancellation instruction (MT192 / MT292) message, the system will match the MT192 / MT292 with the original message. When the matching is successful, if the remittance scenario has been processed and the message has been sent, the original report state remains unchanged. If the remittance message has not been processed and has not been sent, GUPP will set the original report state to wait for return, and the MT192 / MT292 will become SERVICE_WAIT state. If the matching is unsuccessful, GUPP will generate MT196 / MT296.

[0183] Rules for automatic matching of MT192 / MT292 with original message:

[0184] The sender of MT192 / MT292 is equal to the sender of the original message;

[0185] The 21st field of MT192 / MT292 is equal to the original 20th field of the original message;

[0186] The original message type is MT202, MT202 COV (in the case of MT292);

[0187] MT192 / MT292 message into GUPP will also enter the query system (IARS), and by its establishment of query case number (CaseID), and get the original message information. IARS according to the message information returned by GUPP, send operation instruction electric (N96) to GUPP. IARS operation instruction and GUPP can be automatically associated, teller can view the operation instruction in the link of the original message. In this process, the original message will be in the APPROVE_CANCEL state.

[0188] ii) not received the other party line cancellation instruction, but due to some business reasons, the need to do the previous received some message stop payment processing. At this point, the need for teller to do Cancel operation on the original message, the original message state becomes a waiting for the state of the return.

[0189] 2. based on the operation instruction of IARS, the teller decides whether to terminate the original report in GUPP processing, that is, to discard the message, complete the cancellation.

[0190] If the teller decides to cancel, click Approve button, the message state becomes Cancelled. If you need to return, at this time, the business personnel can click RETURN button to return.

[0191] If the teller decides not to cancel, click Refuse button. For scenario i, if the original report is changed to APPROVE_CANCEL state by matching N92, click Refuse, the system pops up N96 message sending page, the teller submits N96 message, and the original report returns to the state before APPROVE_CANCEL. For scenario ii, if the original report is changed to APPROVE_CANCEL state by the teller through the Cancel button, the original report state directly returns to the state before APPROVE_CANCEL after the Refuse operation is successful. (When the message meets the conditions of loan path for SWIFT and (message type for MT196 or MT296), PIP will intercept the message and discard it, not to send it out.)

[0192] At this point, the cancellation and stop payment processing is complete in the system. Subsequently, business personnel will determine whether a refund report needs to be sent to the other bank, depending on the specific business scenario. See the "Initiating a Refund" section below for specific scenarios and procedures.

[0193] IV. Initiating a refund

[0194] In specific implementation, such as Figure 3 As shown:

[0195] Depending on the specific circumstances of the original report, determine whether and how to send the refund telegram.

[0196] 1. When the original message is pending, clicking RETURN will not automatically replace the pending account with the debit account. You need to manually change the debit account of the returned message to account 8341.

[0197] 2. For the four other bank offices, click the Return button to process the refund. If the original message's debit MOP is SWIFT, the generated refund message type will be MT202; if the original message's debit MOP is CHATS, the generated refund message type will be the same as the original message type. Clicking the Return button will bring up the refund message sending page, which automatically displays the debit account (original message credit account), credit account (original message debit account), and the 72-stage refund indicator.

[0198] 3. If the original report has not yet been recorded, and the original report channel is SWIFT, a notification can be sent directly through IARS without initiating a return report message. If the original report channel is local clearing, the clearing account needs to be balanced, so the credit side of the original report needs to be manually changed to the transition account (999) to process the original report. Then click Return to generate a return report message with a debit side of 999 according to the standard in (2).

[0199] 4. If a refund fee is required, the system supports two methods: automatic fee configuration and manual fee collection. Automatic fee configuration follows the Asia Pacific, Europe, and Africa (APEA) rules. For manual fee collection: add a record in the Fee Tab, select Fee Type, Fee Formula, fill in the fee amount and currency, and check "Suppress system fees." GUPP will then only charge based on the added fee entry and will not calculate fees according to the original fee rules during processing. If the refund amount differs from the original amount due to fee-related or other business reasons, the refund report amount can be manually modified.

[0200] 5. GUPP initiated return message, if the debit account is a local clearing account, no debit authorization check: including the return transaction generated by clicking the RETURN button and the return message created manually in the CL interface, if the debit account is a local clearing account, no debit authorization check.

[0201] 6. For the received PI / SN message, all SN messages cannot be returned by clicking the RETURN / REJECT button, whether they have been successfully matched or not, that is, the SN message has no RETURN / REJECT button. PI messages that have not been successfully matched and are in the PAYSET state cannot be returned by clicking the RETURN / REJECT button, and the PI message in this state has no RETURN / REJECT button. Only PI messages that have been successfully matched can be returned by clicking the RETURN / REJECT button.

[0202] For received SN messages, if the PI matching is not successful, manual MTn96 / MTn99 / MT202 can be created to return the message, and manual external account adjustment is performed.

[0203] 7. According to the different posting states before the APPROVE_CANCEL state of the original message, the teller needs to process the message accordingly, and then initiate the return message. The following details the original processing method and account processing:

[0204] (1) The original message has been successfully posted before the APPROVE_CANCEL state. Click the Return button to pop up the return message sending page, which automatically brings out the debit account (the credit account of the original message), the credit account (the debit account of the original message), the 72 field return identifier,

[0205] Confirm that the message information is correct, click Submit to submit the message, and the message status changes to Verify.

[0206] After the Verify operation, the message is processed subsequently, and the message is Complete after processing is completed.

[0207] The posting entry is:

[0208] Dr: original message credit account;

[0209] Cr: 8321;

[0210] Dr: 8321;

[0211] Cr: original message debit account;

[0212] After the return message processing is completed, the original message status changes to Returned, and the original message and the return message can be linked to each other.

[0213] (2) The state of the original message APPROVE_CANCEL is not Complete, and the debit has been posted.

[0214] After the return message is initiated, the debit account of the return message is manually selected as the posted account of the original message (8341), the message information is confirmed to be correct, the Submit button is clicked to submit the message, and the message state is changed to Verify. After the Verify operation, the message is processed subsequently, and the message is completed after the processing is completed. The posting entries are as follows:

[0215] Dr: 8341;

[0216] Cr: 8321;

[0217] Dr: 8321;

[0218] Cr: the credit account of the return message;

[0219] After the processing of the return message is completed, the state of the original message is changed to Returned, and the original message and the return message can be linked to each other.

[0220] (3) The state of the original message APPROVE_CANCEL is not Complete, and no account processing is performed, and the channel of the original message is local clearing. In this scenario, the clearing account needs to be balanced, so the debit account of the original message needs to be manually changed to a transition account (999), the original message needs to be landed, and then the steps in (1) are referred to to initiate a return message with a debit of 999. After the message is processed, the return is initiated.

[0221] The posting entries of the return message are as follows:

[0222] Dr: 999 or a special account for return;

[0223] Cr: 8321;

[0224] Dr: 8321;

[0225] Cr: the debit account of the original message.

[0226] In summary, after the GUPP system receives the return transaction, the system completes the following functions:

[0227] 1. Return transaction identification;

[0228] 2. Matching of the return transaction and the original message;

[0229] 3. Subsequent processing of the return transaction and the original message.

[0230] The core module of the embodiment of the present application is to formulate a flexible and configurable processing flow of cancellation and refund.

[0231] The embodiment of the present application can flexibly cope with the cancellation and refund requirements raised by branches, and can realize various changes of the cancellation and refund business scenarios without modifying system codes. Therefore, the system function is expanded, and the system flexibility and configurability are improved.

[0232] The embodiment of the present application further provides a flexible and configurable transaction refund processing system, as described in the following embodiment. Since the system solving principle is similar to the flexible and configurable transaction refund processing method, the implementation of the system can refer to the implementation of the flexible and configurable transaction refund processing method, and the repeated parts will not be described again.

[0233] Figure 5 The structure diagram of the flexible and configurable transaction refund processing system in the embodiment of the present application is shown in FIG. 1, and the system includes: Figure 5

[0234] The first financial institution 01 is configured to send a cancellation message to the second financial institution for the current transaction when it is identified that the current transaction is a transaction to be refunded.

[0235] The second financial institution 02 is configured to determine the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and send a refund message to the first financial institution according to the transaction refund processing strategy.

[0236] In one embodiment, the second financial institution is specifically configured to:

[0237] The determination of the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy is: the cancellation and refund processing strategy of SWIFT, SWIFTFinCopy, and local clearing proprietary format payment message, and the refund message is sent to the first financial institution according to the transaction refund processing strategy.

[0238] In one embodiment, the cancellation and refund processing strategy of SWIFT, SWIFTFinCopy, and local clearing proprietary format payment message includes:

[0239] The refund message is automatically matched with the original message.

[0240] ​The automatic matching failed return report will enter the ROFi queue, and the original report meeting the preset manual matching rule will be screened out for manual selection and matching by the business personnel;

[0241] If the automatic matching and manual matching both fail, the report needing to be processed is found from the return report queue;

[0242] When the return report received in the automatic processing of the transfer report scene is determined as the final report sent to the original report line.

[0243] In one embodiment, the second financial institution is specifically used for:

[0244] According to the current transaction business demand scene and the relationship between the pre-configured business demand scene and the transaction return processing strategy, it is determined that the transaction return processing strategy corresponding to the current transaction business demand scene is: the return processing strategy of the Pacs008, Pacs003 report of the G3BULK import and export transaction, and the return report is sent to the first financial institution according to the return processing strategy;

[0245] Or, according to the current transaction business demand scene and the relationship between the pre-configured business demand scene and the transaction return processing strategy, the second financial institution determines that the transaction return processing strategy corresponding to the current transaction business demand scene is: according to the report type Pacs004, MT103, MT202, CHIPS, FED return report strategy, the return report is sent to the first financial institution;

[0246] Or, according to the current transaction business demand scene and the relationship between the pre-configured business demand scene and the transaction return processing strategy, the second financial institution determines that the transaction return processing strategy corresponding to the current transaction business demand scene is: according to the original payment report matched from the cancellation report, the strategy of generating the return report associated with the original payment report for the original payment report, and the return report is sent to the first financial institution.

[0247] In one embodiment, the return processing strategy of the Pacs008, Pacs003 report of the G3BULK import and export transaction, or the report type Pacs004, MT103, MT202, CHIPS, FED return report strategy, or the strategy of matching the original payment report from the cancellation report and generating the return report associated with the original payment report for the original payment report includes:

[0248] The return report and the original report are automatically matched according to the preset rule;

[0249] After the automatic matching is successful, the return report needs to link the original report, and the AFTER report 21 field of the return report is equal to the original 20 field of the original report;

[0250] If it is a transfer, the receiving line of the return message should be equal to the first valid debit of the original message, and the After message meets the preset mapping rules;

[0251] If both automatic matching and manual matching fail, find the message to be processed from the return message queue;

[0252] If a Pacs009 non-standard return message with INTERO MOP debit from the online line is received, this type of message is not supported to enter the return flow process, and manual processing is required for this type of message.

[0253] The embodiment of the present application also provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the flexible configurable transaction return processing method when executing the computer program.

[0254] The embodiment of the present application also provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the flexible configurable transaction return processing method.

[0255] The embodiment of the present application also provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the flexible configurable transaction return processing method.

[0256] In the embodiment of the present application, the flexible configurable transaction return processing scheme comprises: when the first financial institution identifies that the current transaction is a transaction to be returned, the first financial institution sends a cancellation message to the second financial institution for the current transaction; the second financial institution determines the transaction return processing strategy corresponding to the business demand scenario of the current transaction according to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction return processing strategy, generates a return message according to the transaction return processing strategy, and sends the return message to the first financial institution. The present application can flexibly cope with the cancellation and return requirements of branches, and various changes of the cancellation and return business scenarios can be realized without modifying the system code, thereby not only expanding the system function, but also improving the flexible configurability of the system.

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

[0258] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.

[0259] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.

[0260] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.

[0261] The above-described specific embodiments are merely intended to further describe and explain the purpose, technical solutions and beneficial effects of the present application, and should be understood that the above-described specific embodiments are merely specific embodiments of the present application and are not used to limit the protection scope of the present application, and any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A flexible configurable transaction refund processing method, characterized in that, The method comprises the following steps: When the first financial institution identifies that the current transaction is a transaction to be refunded, the first financial institution sends a cancellation message to the second financial institution for the current transaction; The second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and sends a refund message to the first financial institution according to the transaction refund processing strategy, which comprises the following steps: The second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and sends a refund message to the first financial institution according to the transaction refund processing strategy, wherein the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: the cancellation and refund processing strategy of SWIFT, SWIFTFinCopy, and local clearing proprietary format payment message, and the cancellation and refund processing strategy of SWIFT, SWIFTFinCopy, and local clearing proprietary format payment message comprises the following steps: automatically matching the refund message with the original message; the refund message that fails in automatic matching will enter the ROFi queue, and the original message that meets the preset manual matching rule is screened out for manual selection and matching by business personnel; if both automatic matching and manual matching fail, the message to be processed is found from the refund message queue; when the received refund message in the automatic processing and transfer message scenario is processed, the message field number finally sent to the original message sender is determined. Or, the second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and sends the refund message to the first financial institution according to the refund processing strategy of the Pacs008, Pacs003 message of the G3BULK import and export transaction; or, the second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and sends the refund message to the first financial institution according to the refund message strategy of the message type Pacs004, MT103, MT202, CHIPS, FED; or, the second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and sends the refund message to the first financial institution according to the strategy of matching the original payment message from the cancellation message and generating the refund message associated with the original payment message for the original payment message; wherein, the refund processing strategy of the Pacs008, Pacs003 message of the G3BULK import and export transaction, or the message type Pacs004, MT103, MT202, CHIPS, FED refund message strategy, or the strategy of matching the original payment message from the cancellation message and generating the refund message associated with the original payment message for the original payment message, includes: automatically matching the refund message with the original message according to a preset rule; after automatic matching is successful, the refund message needs to link the original message, and the AFTER message 21 field of the refund message is equal to the original 20 field of the original message; if it is a transfer, the receiving line of the refund message should be equal to the first valid debit of the original message, and the After message meets the preset mapping rule; if automatic matching and manual matching both fail, find the message to be processed from the refund message queue; if a Pacs009 non-standard refund message with INTERO MOP debit from the online line is received, this type of message is not supported to enter the refund process, and manual processing is required for this type of message.

2. A flexible configurable transaction refund processing system characterized by, Comprise: The first financial institution is configured to send a cancellation message to the second financial institution for the current transaction when identifying that the current transaction is a transaction to be refunded; The second financial institution is configured to determine the transaction refund processing strategy corresponding to the business demand scenario of the current transaction according to the relationship between the business demand scenario of the current transaction and the pre-configured business demand scenario and transaction refund processing strategy, and send the refund message to the first financial institution according to the transaction refund processing strategy, which comprises: According to the business requirement scenario of the current transaction and the relationship between the pre-configured business requirement scenario and the transaction refund processing strategy, the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction is determined as: SWIFT, SWIFTFinCopy, and local clearing proprietary format payment message cancellation and refund processing strategy. According to the transaction refund processing strategy, the refund message is sent to the first financial institution; wherein the SWIFT, SWIFTFinCopy, and local clearing proprietary format payment message cancellation and refund processing strategy includes: automatically matching the refund message with the original message; the refund message that fails to be automatically matched will enter the ROFi queue, and the original message that meets the pre-set manual matching rule is screened out for manual selection and matching by business personnel; if both automatic matching and manual matching fail, the message to be processed is found from the refund message queue; when automatically processing the received refund message in the transfer processing scenario, the message field number finally sent to the original message sending line is determined. Or, according to the business requirement scenario of the current transaction and the relationship between the pre-configured business requirement scenario and the transaction refund processing strategy, it is determined that the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction is: the Pacs008, Pacs003 message refund processing strategy of G3BULK import and export transaction, and the refund message is sent to the first financial institution according to the refund processing strategy; or, according to the business requirement scenario of the current transaction and the relationship between the pre-configured business requirement scenario and the transaction refund processing strategy, it is determined that the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction is: according to the message type Pacs004, MT103, MT202, CHIPS, FED refund message strategy, the refund message is sent to the first financial institution; or, according to the business requirement scenario of the current transaction and the relationship between the pre-configured business requirement scenario and the transaction refund processing strategy, it is determined that the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction is: according to the original payment message matched from the cancellation message, the strategy of generating the refund message associated with the original payment message for the original payment message, and the refund message is sent to the first financial institution; wherein, the Pacs008, Pacs003 message refund processing strategy of G3BULK import and export transaction, or the message type Pacs004, MT103, MT202, CHIPS, FED refund message strategy, or the strategy of matching the original payment message from the cancellation message and generating the refund message associated with the original payment message for the original payment message, includes: automatically matching the refund message with the original message according to the preset rule; after automatic matching is successful, the refund message needs to link the original message, and the AFTER message 21 field of the refund message is equal to the original 20 field of the original message; if it is a transfer, the receiving line of the refund message should be equal to the first valid debit of the original message, and the After message meets the preset mapping rule; if automatic matching and manual matching both fail, find the message to be processed from the refund message queue; if the Pacs009 non-standard refund message with INTERO MOP debit from the online line is received, this type of message is not supported to enter the refund process, and manual processing is required for this type of message.

3. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to realize the method of claim 1.

4. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to realize the method of claim 1.

5. A computer program product, characterised in that, The computer program product comprises a computer program, and the computer program is executed by the processor to realize the method of claim 1.

Images