CN115525328A - Flexibly configurable transaction refund processing method and system - Google Patents

Abstract

The invention discloses a flexible and configurable transaction refund processing method and system, and relates to the technical field of financial processing, wherein the method includes: when a first financial institution recognizes that the current transaction is a transaction to be refunded, sending a cancellation for the current transaction The message is sent to the second financial institution; the second financial institution determines the transaction refund corresponding to the business requirement scenario of the current transaction according to the business demand scenario of the current transaction and the relationship between the pre-configured business requirement scenario and the transaction refund processing strategy The processing strategy is to send the remittance refund message to the first financial institution according to the transaction remittance refund processing strategy. The present invention can flexibly respond to the revocation and remittance refund requirements proposed by various financial institutions, and can realize various changes in the revocation and remittance refund business scenarios without modifying the system code, thereby not only expanding the system function, but also improving the system efficiency Flexible configurability.

Description

Flexible and configurable transaction refund processing method and system

technical field

The invention relates to the technical field of financial processing, in particular to a flexible and configurable transaction refund processing method and system.

Background technique

This section is intended to provide a background or context to embodiments of the invention that are recited in the claims. The descriptions herein are not admitted to be prior art by inclusion in this section.

At present, the revocation and remittance refund business processing in the payment and settlement field of the financial industry usually uses the form of development code to directly write the processing logic of revocation and remittance refund business. If the business requirements change, and the revocation and refund scenarios change, in order to add new logic, it may be necessary to modify the code, which takes a long time and is not very flexible.

Contents of the invention

The embodiment of the present invention provides a flexible and configurable transaction refund processing method, which is used to flexibly respond to the revocation and refund requirements of various financial institutions, and can realize various cancellation and refund business scenarios without modifying the system code. Changes to expand system functions and improve the flexibility and configurability of the system, the method includes:

When the first financial institution recognizes that the current transaction is a transaction to be refunded, it sends a cancellation message to the second financial institution for 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 refund processing strategy, the second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction. The remittance processing strategy is used to send the remittance refund message to the first financial institution.

The embodiment of the present invention also provides a flexible and configurable transaction refund processing system, which is used to flexibly respond to the revocation and refund requirements of various financial institutions, and can realize the revocation and refund business scenarios without modifying the system code Various changes to expand system functions and improve system flexibility and configurability, the system includes:

The first financial institution is configured to send a revocation message for the current transaction to the second financial institution when identifying that the current transaction is a transaction to be refunded;

The second financial institution is used to determine 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 pre-configured business requirement scenario and the transaction refund processing strategy. According to the above-mentioned transaction refund processing strategy, the refund message is sent to the first financial institution.

An embodiment of the present invention also provides a computer device, including a memory, a processor, and a computer program stored on the memory and operable on the processor. When the processor executes the computer program, the above-mentioned flexible and configurable transaction refund sink processing method.

An embodiment of the present invention also provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned flexible and configurable transaction refund processing method is realized.

An embodiment of the present invention also provides a computer program product, the computer program product includes a computer program, and when the computer program is executed by a processor, the above-mentioned flexible and configurable transaction refund processing method is realized.

In the embodiment of the present invention, the flexible and configurable transaction refund processing scheme is through: when the first financial institution recognizes that the current transaction is a transaction to be refunded, it sends a cancellation message to the second financial institution for the current transaction; the second financial institution According to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction, and according to the transaction refund processing strategy , and send the refund message to the first financial institution. The present invention can flexibly respond to the revocation and remittance refund requirements proposed by the branch, and can realize various changes in revocation and remittance refund business scenarios without modifying the system code, thereby not only expanding the system function, but also improving the flexible configurability of the system .

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some embodiments of the present invention. Those skilled in the art can also obtain other drawings based on these drawings without creative work. In the attached picture:

Fig. 1 is a schematic flow chart of the processing and operation of receiving a remittance call in an embodiment of the present invention;

Fig. 2 is a schematic diagram of receipt of the other party's cancellation instruction and stop payment processing in the embodiment of the present invention;

Fig. 3 is a schematic diagram of initiating a remittance refund in an embodiment of the present invention;

Fig. 4 is a schematic flowchart of a flexible and configurable transaction refund processing method in an embodiment of the present invention;

Fig. 5 is a schematic structural diagram of a flexible and configurable transaction refund processing system in an embodiment of the present invention.

detailed description

In order to make the purpose, technical solutions and advantages of the embodiments of the present invention more clear, the embodiments of the present invention will be further described in detail below in conjunction with the accompanying drawings. Here, the exemplary embodiments and descriptions of the present invention are used to explain the present invention, but not to limit the present invention.

The acquisition, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

The term "and/or" in this article only describes an association relationship, which means that there can be three kinds of relationships, for example, A and/or B can mean: there is A alone, A and B exist at the same time, and B exists alone. situation. In addition, the term "at least one" herein means any one of a variety or any combination of at least two of the more, for example, including at least one of A, B, and C, which may mean including from A, Any one or more elements selected from the set formed by B and C.

In the description of this specification, the words "comprising", "comprising", "having", "containing" and so on are all open terms, meaning including but not limited to. A description referring to the terms "one embodiment," "a particular embodiment," "some embodiments," "for example," etc., means that a particular feature, structure, or characteristic described in connection with the embodiment or example is included in at least one of the present application. Examples or examples. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the described specific features, structures or characteristics may be combined in any suitable manner in any one or more embodiments or examples. The sequence of steps involved in each embodiment is used to schematically illustrate the implementation of the present application, and the sequence of steps therein is not limited and can be appropriately adjusted as required.

The payment and settlement system is a very important part of the bank's IT system, and most of the banking business needs to rely on the payment and settlement system. GUPP (Global Unified Payment Platform) provides payment and settlement services for all overseas branches of Bank of China. GUPP adopts a global logic centralized and unified deployment method to give full play to the advantages of internal messages, further improve payment and settlement efficiency, and reduce operating costs.

Revocation means that a financial institution sends an 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. Payment stop refers to the cancel processing in GUPP. The process includes canceling and stopping payment for messages that have not completed account processing. If all accounts have been processed, it has nothing to do with stop payment. Refund refund means that the bank receives the cancellation message and decides to return the position to the applicant bank; or due to some reasons, we cannot process the message correctly and send a refund message to the counterparty bank.

At present, the revocation and remittance refund business processing in the payment and settlement field of the financial industry usually uses the form of development code to directly write the processing logic of revocation and remittance refund business. If the business scenario changes, the code needs to be modified, which makes the system function inflexible. The disadvantage of using code to determine business logic is that it is not flexible enough. That is to say, if the business requirements change, and the revocation and refund scenarios change, in order to add new logic, it may be necessary to modify the code, which takes a long time and is not very flexible.

In order to support various complex revocation and remittance refund scenarios in the field of bank payment and settlement, the embodiment of the present invention provides a flexible and configurable transaction remittance processing solution, that is, GUPP invented a set of configurable The processing mechanism and business requirement scenarios are as follows:

1) Revocation and remittance processing of SWIFT, SWIFTFinCopy, and local clearing proprietary format payment messages;

2) Remittance processing for Pacs008 and Pacs003 messages of G3BULK inward and outward transactions;

3) The message type is Pacs004, MT103, MT202, CHIPS, FED return message;

4) For the original report, click the Return button to generate a return message associated with the original report.

The above scenario "1)" is a business requirement scenario in the SWIFT standard format, and scenarios "2)-4)" are business requirement scenarios in a non-SWIFT standard format.

Revocation processing means that one financial institution sends an MT192/MT292 message to another financial institution as a revocation request, requesting the latter to cancel the original message specified in the MT192/MT292 message.

According to the different active initiators in the revocation process, the revocation process is divided into two cases: receiving a revocation message and sending a revocation message. In the case of receiving a revocation message, it is divided into receiving a revocation message and receiving a revocation message in an import business scenario according to different business scenarios. The transfer scenario receives the revocation message.

Undo:

For the scenario of receiving MT192/MT292: from the time the system receives MT192/MT292 to the time when the system sends MTn96 (refusal to cancel) or the GUPP system decides to withdraw the remittance, the whole process is the cancellation process.

For the scenario of sending MT192/MT292: from the time the system sends the MT192/MT292 message to the time the system receives the feedback message sent by the receiving bank, the whole process is called the revocation process.

stop payment:

The stop payment process refers to the accounting level, which refers to the cancel processing in GUPP. The process includes canceling and stopping payment for messages that have not completed the accounting processing. If the accounts have been fully processed, it has nothing to do with stopping payment.

Refund exchange:

After receiving the cancellation message, we decide to cancel the position and return the position to the applicant bank; or for some reasons, we cannot process the message correctly, and we will send a refund message to the counterparty bank.

According to the definition of the project scope and product functions, the business scope supported by GUPP is limited to the revocation and refund processing of SWIFT, SWIFT Fin Copy, local clearing proprietary format payment messages processed by GUPP, and GUPP also supports G3BULK import and export Transaction refund processing of Pacs008 and Pacs003 messages. The types of refund packets supported by GUPP include: Pacs004, MT103, MT202, CHIPS, and FED refund packets. GUPP does not support the automatic processing of the return message received when the original message received a double battery but sent a single battery.

In the scenario where our bank receives a revocation message and sends a refund message, the system supports matching the received MT192/MT292 to the original report, and clicks the Return button on the original report to generate a standard SWIFT refund message associated with the original report.

To sum up, in the embodiment of the present invention: 1. Code developers need to separate the various business scenarios of revocation and remittance, and make them into small components, which is convenient for subsequent configuration developers to combine. 2. Configuration Developers need to configure the rules for revocation and refund, so as to more conveniently realize the different needs of branches. The design and development of its rules require multiple rounds of clarification with the business. The following is a detailed introduction to the flexible and configurable transaction refund processing scheme.

Fig. 4 is a schematic flowchart of a flexible and configurable transaction refund processing method in an embodiment of the present invention. As shown in Fig. 4, the method includes the following steps:

Step 101: When the first financial institution recognizes that the current transaction is a transaction to be refunded, it sends a cancellation message to the second financial institution for the current transaction;

Step 102: The second financial institution determines the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction according to the business demand scenario of the current transaction and the relationship between the pre-configured business requirement scenario and the transaction refund processing strategy, and according to the According to the above-mentioned transaction refund processing strategy, the refund message is sent to the first financial institution.

The flexible and configurable transaction refund processing method provided by the embodiment of the present invention works: when the first financial institution recognizes that the current transaction is a transaction to be refunded, it sends a cancellation message to the second financial institution for 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 refund processing strategy, the financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction, and processes the refund according to the transaction strategy, sending the refund message to the first financial institution. The present invention can flexibly respond to the revocation and remittance refund requirements proposed by the branch, and can realize various changes in revocation and remittance refund business scenarios without modifying the system code, thereby not only expanding the system function, but also improving the flexible configurability of the system . The following is a detailed introduction to the flexible and configurable transaction refund processing method.

In one embodiment, 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 pre-configured business requirement scenario and the transaction refund processing strategy , according to the transaction refund processing strategy, send the refund message to the first financial institution, including:

According to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: SWIFT, SWIFTFinCopy, The revocation and remittance processing strategy of the payment message in the local clearing proprietary format, according to the transaction remittance processing strategy, sends the remittance message to the first financial institution.

During specific implementation, in the face of the above "1)" being a business requirement scenario in the SWIFT standard format, the remittance refund message is sent to the first financial institution according to the revocation of the payment message in the proprietary format of SWIFT, SWIFFTFinCopy, and local clearing and the remittance processing strategy , further improving the flexibility and configurability of the system.

In one embodiment, the revocation and remittance processing strategies of SWIFT, SWIFTFinCopy, and local clearing proprietary format payment messages include:

Automatically match the refund message with the original message;

Return packets that fail to be automatically matched will enter the ROFi queue, and the original packets that meet the preset manual matching rules will be screened out for business personnel to manually select and match;

If both automatic matching and manual matching fail, find the message that needs to be processed from the return message queue;

When automatically processing the refund message received in the remittance scenario, determine the number of times the message will be finally sent to the original message sending bank.

In specific implementation, the detailed implementation of the above-mentioned SWIFT, SWIFFTFinCopy, and local clearing proprietary format payment message revocation and remittance processing strategies further improves the flexibility and configurability of the system.

In one embodiment, 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 preconfigured business requirement scenario and the transaction refund processing strategy, According to the transaction refund processing strategy, send the refund message to the first financial institution, including:

According to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: G3BULK Inward Remittance The remittance processing policy of the Pacs008 and Pacs003 messages of the transaction, according to the remittance processing strategy, the remittance message is sent to the first financial institution;

Or, according to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: The file type is Pacs004, MT103, MT202, CHIPS, FED refund message policy, and send the refund message to the first financial institution;

Or, according to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: The original payment message is matched in the revocation message, and the policy of generating a remittance refund message associated with the original payment message according to the original payment message is sent to the first financial institution.

During specific implementation, in the face of the above "2)-4)" business requirement scenarios that are not in the SWIFT standard format, according to the remittance processing strategy of the Pacs008 and Pacs003 messages of the G3BULK import and export transaction, the message types are Pacs004, MT103, MT202, CHIPS, FED refund message policy, match the original payment message from the revocation message, generate a policy of refund message associated with the original payment message according to the original payment message, and send the refund message to the first financial The organization further improves the flexibility and configurability of the system.

In one embodiment, the Pacs008 and Pacs003 messages of the G3BULK import and export transaction have a refund processing policy, or the message type is Pacs004, MT103, MT202, CHIPS, and FED, or match from the cancel message Generate the original payment message, and generate a refund message associated with the original payment message for the original payment message, including:

Automatically match the refund message with the original message according to the preset rules;

After the automatic matching is successful, the return message needs to be linked to the original message, and the 21 fields of the AFTER message of the return message are equal to the original 20 fields of the original message;

If it is a remittance transfer, the receiving line of the return message should be equal to the first effective debit of the original message, and the After message complies with the preset mapping rules;

If both automatic matching and manual matching fail, find the message that needs to be processed from the return message queue;

If you receive a Pacs009 non-standard refund message from the upline bank whose debit MOP is INTERO, this kind of message is not supported to enter the refund process, and such messages need to be processed manually.

During the specific implementation, the above-mentioned G3BULK import and export transaction Pacs008, Pacs003 message refund processing strategy, or the message type is Pacs004, MT103, MT202, CHIPS, FED refund message policy, or match from the cancellation message For the original payment message, the detailed implementation of the policy of generating the refund message associated with the original payment message for the original payment message further improves the flexibility and configurability of the system.

In order to facilitate understanding of how the present invention is implemented, a detailed introduction will be made below in conjunction with FIG. 1 to FIG. 3 .

1. Initiate a revocation order

1. GUPP actively initiates the cancellation command MT192/MT292 (in the export scenario)

GUPP cannot directly initiate the MT192/MT292 cancellation order. The implementation method is as follows: For the export message that needs to be canceled, click Query to initiate a transfer query, and indicate that it needs to be revoked in the transfer query information. The system generates MTn95 and sends it to IARS. After receiving the query, IARS sends MT192/MT292 to the counterparty bank according to the cancellation request, so as to realize the function of sending cancellation instructions from GUPP.

2. The counterparty bank responds to the cancellation instruction issued by our bank

After receiving the MT192/MT292 issued by our bank (such as the second financial institution, GUPP (Global Unified Payment Platform)), the counterparty bank (such as the first financial institution, which can be a branch), according to different business scenarios (the four mentioned above) different business demand scenarios), we will give different replies to our bank.

(1) The counterparty bank cancels the original message according to the cancellation command (if it has already been accounted for), and sends a remittance wire (MT103/MT202) to our bank.

For detailed handling of GUPP’s receipt of remittance remittances, see the description in the subsequent section “Receipt of Remittance Remittances” in this section.

(2) The counterparty bank replies the MTn96/MTn99 message to our bank in response to the cancellation instruction (if the account has not yet been booked).

The other party replies to our bank with an MTn96 message, and there are several possible scenarios as follows:

(1) Due to some reasons, the other bank cannot cancel the original message.

(2) The original message has not been accounted for, and the bank is notified of the successful cancellation.

For the scenario where the MTn96 message is received, the business personnel perform corresponding operations according to the instructions.

2. Receipt of remittance

After receiving the cancellation instruction initiated by our bank, the counterparty bank will send a wire transfer refund to our bank according to the original message.

There are also some scenarios where our bank does not take the initiative to initiate a cancellation order, but the counterparty bank initiates a remittance refund to our bank for some reasons (for example: the original message is wrong, and the counterparty bank cannot enter the account).

Whether it is our bank's request to cancel, or the other bank's initiative to refund the remittance. The processing and operation of the GUPP system to receive the refund and remittance follow the same process as shown in Figure 1.

1. The receiving bank of the original payment message sends a refund position message to GUPP.

2. Reports containing any one of 'RETURN', 'REFUND', 'REJECT', 'RETN', 'REJT', and 'RTN' in 72 fields (when the message type is MT202, 58 fields = this office) The text will enter the special processing flow of the refund message, and then match the original report, as shown in 3. Otherwise, messages that do not meet the above conditions will not enter the processing flow of return messages.

3. The message that enters the special processing process of remittance refund will be matched with the original message.

I. Determine whether the refund message type is a refund message that conforms to the SWIFT standard format:

报文类型为MT103，MT202，MT202COV，MT205；

The message types are MT103, MT202, MT202COV, MT205;

72场第一行包含code word:/RETN/或/REJT/；

The first line of field 72 contains code word: /RETN/ or /REJT/;

72场第三行包含code word:/MREF/；

Field 72, the third line contains the code word: /MREF/;

借方MOP不等于BOOK，贷方MOP非空。

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

If the conditions of Scenario I (SWIFT specification format scenario) are met, proceed according to the procedure described below; otherwise, proceed according to Procedure II.

(1) The refund message is first automatically matched with the original message, and the matching rules are as follows:

退汇报文的发报行等于原报文的收报行。

The sending line of the return message is equal to the receiving line of the original message.

原报报文状态不是REJECTED或RETURNED。

The status of the original message is not REJECTED or RETURNED.

原报文类型为MT103，MT202，MT202COV，MT205。

The original message types are MT103, MT202, MT202COV, MT205.

72场第一行包含code word:/RETN/或/REJT/。

Field 72 The first line contains the code word: /RETN/ or /REJT/.

退汇报文72场的/MREF/关键字下的内容等于原报的20场(Instr ID)。

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

(2) Returned packets that fail to be automatically matched will enter the ROFi queue, and the system will automatically filter out the original packets that meet the following manual matching rules for business personnel to manually select and match:

原报文是PAY电；

The original message is PAY telegram;

原报文和退汇报文都是MT103、MT202、MT202COV、MT205；

Both the original message and the return message are MT103, MT202, MT202COV, MT205;

退汇报文72场第一行不包含/RETN/或者不包含/REJT/；

The first line of field 72 of the return message does not contain /RETN/ or does not contain /REJT/;

原报文状态是COMPLETE；

The status of the original message is COMPLETE;

退汇报文的32场金额在差值容忍范围内。(通过系统参数RJCT_TOLERANCE_PRCNT设置)；

The amount in 32 fields of the return report is within the tolerance range of the difference. (set by system parameter RJCT_TOLERANCE_PRCNT);

退汇报文起息日跟原报文的32场起息日相差三天内。

The difference between the value date of the return report and the 32 field value dates of the original report is within three days.

(3) If both automatic matching and manual matching fail, the teller finds the message that needs to be processed from the refund message queue. If it is a SWIFT message, use the information after 72 fields /MREF/ of the refund message (the original message 20 sessions), you can manually add the MID of the refund message to the Notes of the original report for marking and association. At the same time, Cancel the original message and Cancel the refund message. If the original message is a remittance message, you need to manually adjust the account in the core system; if the original message is a transfer message, you need to create a new refund report in the GUPP system. In the text, 72 fields contain the remittance refund flag, and the system will process the newly created remittance refund transaction according to the HighValue Workflow that sends the remittance refund message.

(4) When GUPP automatically processes the refund message received in the remittance transfer scenario, the event times of the message finally sent to the original message sending bank are as follows:

Return report message F20=GUPP newly generates F20;

Return report message F21=F21 received by the original message;

Return report message F50 = F50 received by the original message;

Return report message F57=F57 received by the original message;

Return report message F58=F58 received by the original message;

Return report message F59=F59 received by the original message;

The number after /MREF/ of the return report message F72=the F20 received in the original message.

II. If the return return message is in a non-SWIFT standard format (that is, business scenario II is a business requirement scenario that is not in a SWIFT standard format), determine whether the return return message meets the following conditions:

报文类型是MT202。

The message type is MT202.

72场包含‘RETURN’、‘REFUND’、‘REJECT’、‘RETN’、‘REJT’、‘RTN’中任何一个。

The 72 fields contain any one of 'RETURN', 'REFUND', 'REJECT', 'RETN', 'REJT', 'RTN'.

58场＝本office。

58 fields = this office.

If it is satisfied, process it according to the process described below, otherwise, perform subsequent processing:

(1) The return message is automatically matched with the original message according to the following rules:

退汇报文发报行＝原报文的AFTER报文收报行；

Sending line of return message = AFTER message receiving line of the original message;

退汇报文21场＝原报文的20场；

21 fields of return message = 20 fields of the original message;

退汇报文32场币种＝原始报文32场币种。

The 32 currency fields of the refund message = the 32 currency fields of the original message.

(2) After the automatic matching is successful, the return message needs to be linked to the original message, and the 21 fields of the AFTER message of the return message = the original 20 fields of the original message.

Return packets that fail to be automatically matched will enter the ROFi queue, and the system will automatically filter out the original packets that meet the following manual matching rules for business personnel to manually select and match:

原报文是PAY电；

The original message is PAY telegram;

原报文和退汇报文都是MT103、MT202、MT202COV、MT205；

Both the original message and the return message are MT103, MT202, MT202COV, MT205;

原报文72场不包含‘RETN’、‘REJT’、‘REFUND’、‘RETURN’、‘REJECT’、‘RTN’中的任何一个；

Field 72 of the original message does not contain any of 'RETN', 'REJT', 'REFUND', 'RETURN', 'REJECT', 'RTN';

原报文状态是COMPLETE；

The status of the original message is COMPLETE;

退汇报文的32场金额在差值容忍范围内。(通过系统参数RJCT_TOLERANCE_PRCNT设置)。

The amount in 32 fields of the return report is within the tolerance range of the difference. (Set by the system parameter RJCT_TOLERANCE_PRCNT).

(3) In this scenario, if it is a remittance transfer, the receiving line of the refund message should be equal to the first effective debit of the original message, and the After message mapping rules:

After报文的收报行＝原报文的第一有效借方；

The receiving line of the After message = the first effective debit of the original message;

After报文的21场＝原报文的原始20场；

21 fields of the After message = original 20 fields of the original message;

After报文的32场的起息日、金额和币种等于人工修改后的值；

The value date, amount and currency of the 32 fields of the After message are equal to the manually modified values;

After报文的58场＝原始报文的第一有效借方；

Field 58 of the After message=the first valid debit side of the original message;

After报文的72场等于收到的before报文的72场。(人工修改的情况下，等于修改后的值)。

The 72 fields of the After message are equal to the 72 fields of the received before message. (In the case of manual modification, it is equal to the modified value).

(4) If both automatic matching and manual matching fail, the teller finds the message that needs to be processed from the refund message queue. If it is a SWIFT message, use the information of 21 fields of the refund message (20 fields of the original message), You can manually add the MID of the return message to the Notes of the original report to mark and associate it. At the same time, Cancel the original message and Cancel the refund message. If the original message is a remittance message, you need to manually adjust the account in the core system; if the original message is a transfer message, you need to create a new refund report in the GUPP system. In the text, 72 fields contain the remittance refund mark, and the system will process the newly created remittance refund transaction according to the High Value Workflow that sends the remittance refund message.

(5) If you receive a Pacs009 non-standard refund message from the upline bank whose debit MOP is INTERO (the receiving bank and field 58 are equal to the office, and field 72 contains the refund logo), GUPP does not support such messages to enter the refund For process processing, this type of message needs to be processed manually, and the method is the same as that described in (4).

4. In the above Scenario II (non-standard remittance refund scenario), for a certain branch, if the original report is FED/CHIPS to SWIFT transfer scenario, after receiving the return report from SWIFT, it does not support automatic transfer to FED/CHIPS. The process for receiving non-standard remittance refunds from SWIFT is as follows:

(1) Follow step (1) in Scenario II and perform automatic matching.

(2) Return packets that fail to be matched automatically, enter the ROFI queue, and perform manual matching according to step (2) in Scenario II.

(3) After the matching is successful, the original report and the return report are related to each other, and the original report enters the WAITRETURN state.

(4) Manually change the account number of 58 returns to a transitional account, then process the return to COMPLETE status, and place the returned position on the account of our bank. At this time, the status of the original report changes to RETURNED.

(5) Manually create a FED/CHIPS refund message or an ordinary FED/CHIPS remittance message, select the debit account as the credit account of the refund, that is, the transitional account, and select the lender as the sending bank of the original FED/CHIPS message, Thus, the position will be returned to the original reporting bank through FED/CHIPS.

5. In the case of scenarios I. and II. above, automatically or manually matched refund messages to the original report are placed in the dedicated queue for refund, and the refund amount, value date, and 72 fields can be manually modified.

This requirement follows the implementation method of Asia-Pacific, Europe and Africa, through customized queues and Special instruction, if the 72 fields in the message contain 'RETN', 'REJT', 'REFUND', 'RETURN', 'REJECT', 'RTN' Any flag, then the message will fall into the customized queue 'RETN REJT RFND', and the message will hit the Special instruction at the same time, the message status will change to Repair, and the refund amount, value date, and 72 field information can be manually modified.

The credit account of the original message is used as the debit account of the refund message, the debit account of the original message is used as the credit account of the refund message, and the debit MOP of the original message is used as the credit MOP of the refund message, skipping the debit and credit judgment of GUPP In the MOP judgment link, follow-up exchange rate conversion, fees, Special instruction, etc. are processed.

The state of the associated original message will change to WAITREJECT or WAITRETURN. When the return message is processed and becomes COMPLELE state, the state of the original message will change to REJECTED or RETURNED state accordingly.

6. In the above scenarios I. and II., for other branches, if the original message is in the remittance scenario, if the received refund message matches the original message according to the automatic matching rules, or after the manual matching rules are successfully matched , when the debit MOP of the original message is SWIFT, no matter what type the original message is, the After message type of the return message is MT202; if the debit MOP of the original message is CHATS, the return message The type of the After packet is the same as the type of the original packet.

7. According to the current processing situation of the original message, mainly the accounting situation, that is, judge the credit side of the refund message according to the debit of the original message, and perform the following processing on the refund message according to the situation.

In the scenario where the original message is exported, if the debit of the GUPP original message processing is an intermediate account, not the 50 account of the message, the business personnel need to manually complete the accounting processing between the 50 account and the intermediate account. After GUPP completes the remittance refund process, it is necessary to manually adjust the accounts in the core: debit: cross-system current account 8321 account, credit: the real debit account of the originating channel.

(1) The system recognizes it as a refund message, but both automatic matching and manual matching fail, so you need to cancel the original message, and cancel the refund message:

1) If the original message is an outgoing message, manually adjust the account in the core, and the Posting entry is as follows:

Dr: original message credit account number;

Cr: 8321;

Dr: 8321;

Cr: Debit account of the original message.

2) If the original message is a remittance message, a refund message is sent in GUPP, the message contains 72 fields of the refund identifier, the debit account is the credit account of the original message, and the credit account is the debit account of the original message.

Dr: original message credit account number;

Cr: 8321;

Dr: 8321;

Cr: Debit account of the original message.

(2) The system recognizes it as a refund message and the match is successful

1) The system automatically matches the return message with the original message. After the return message is processed, the status of the return message changes to Complete, and the status of the original message is RETURNED/REJECTED. The corresponding Posting entry should be:

Dr: original message credit account number;

Cr: 8341;

Dr: 8341;

Cr: Debit account of the original message.

8. For the refund message initiated by GUPP, if the debit account is a customer account, Account Lookup needs to be performed. The message screening conditions are as follows:

借方MOP为BOOK；

Debit MOP is BOOK;

报文类型为MT103/202时，假如72场带有”RETURN”，”REFUND”，”REJECT”，“RETN”，“REJT”，‘RTN’字样的做Account Lookup处理。

When the message type is MT103/202, if 72 fields contain "RETURN", "REFUND", "REJECT", "RETN", "REJT", and 'RTN', do Account Lookup processing.

For the refund message received by GUPP, if the credit account is a customer account, Account Lookup needs to be performed. The message screening conditions are as follows:

贷方MOP为BOOK；

The lender MOP is BOOK;

报文类型为MT103/202时，假如72场带有”RETURN”，”REFUND”，”REJECT”，“RETN”，“REJT”，‘RTN’字样的做Account Lookup处理。

When the message type is MT103/202, if 72 fields contain "RETURN", "REFUND", "REJECT", "RETN", "REJT", and 'RTN', do Account Lookup processing.

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

3. Receive the other party’s cancellation order and stop payment

During specific implementation, as shown in Figure 2:

1. Receive cancellation or voluntary stop payment:

i) After receiving the cancellation command (MT192/MT292) message from the counterparty bank, the system will match the MT192/MT292 to the original message. The original status remains unchanged. If the transfer message has not been processed yet sent, GUPP will set the status of the original message to wait for remittance return, and MT192/MT292 will change to SERVICE_WAIT status. If the match is unsuccessful, GUPP will generate MT196/MT296.

MT192/MT292 automatically matches the rules of the original message:

The sending line of MT192/MT292 is equal to the sending line of the original message;

The 21 fields of MT192/MT292 are equal to the original 20 fields of the original message;

The original message type is MT202, MT202COV (in the case of receiving MT292);

When the MT192/MT292 message enters the GUPP, it will also enter the Inquiry Retrieval System (IARS), which will establish an inquiry case file number (CaseID) and obtain the original message information. According to the message information returned by GUPP, IARS sends an operation command (N96) to GUPP. The IARS operation command and GUPP can be automatically associated, and the teller can view the operation command in the link of the original message. During this process, the original message will always be in the APPROVE_CANCEL state.

ii) No cancellation instruction from the counterparty bank has been received, but due to some business reasons, it is necessary to stop payment for a previously received message. At this time, the teller needs to manually cancel the original message, and the status of the original message changes to the status of waiting for remittance refund.

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

If the teller decides to cancel, click the Approve button, and the status of the message will change to Canceled. If remittance is required, at this time, the business personnel can click the RETURN button to return the remittance.

If the teller decides not to cancel and wants to continue processing the original message, click the Refuse button. For scenario i, if the original report changes to the APPROVE_CANCEL state by matching N92, after clicking Refuse, the system pops up the N96 message sending page, and after the teller submits the N96 message, the original report returns from APPROVE_CANCEL to the state before APPROVE_CANCEL. For scenario ii, if the original report is manually changed to the APPROVE_CANCEL state through the Cancel button by the teller, then after the Refuse operation is successful, the original report status will directly return to the state before APPROVE_CANCEL. (When the message satisfies that the credit path is SWIFT and (the message type is MT196 or MT296), PIP intercepts and disables the message and does not send it out.)

So far, the processing of cancellation and stop payment has been completed in the system. Subsequent business personnel determine whether it is necessary to send a refund message to the counterparty bank according to different business scenarios. For specific scenarios and procedures, please refer to the description in the "Initiating Remittance Refund" section below.

4. Initiate refund

During specific implementation, as shown in Figure 3:

According to the different situations of the original report, determine whether to send and how to send the remittance wire.

1. When the original message is debited, click RETURN to return the debit. The debited account cannot be automatically replaced with the debit account. It is necessary to manually change the debit of the refund message to the 8341 account.

2. For the four offices of other banks, click the Return button to refund the remittance. If the debit MOP of the original message is SWIFT, the type of the generated remittance refund message is MT202; if the debit MOP of the original message is CHATS, the generated remittance refund message The type is the same as the original message type. Click the Return button, and the sending page of the refund message will pop up, and the page will automatically display the debit account (the credit account of the original message), the credit account (the debit account of the original message), and 72 refund signs.

3. If the original report has not been accounted for, if the original report channel is SWIFT, the notification can be sent directly through IARS, and there is no need to initiate a refund message. If the original reporting channel is local clearing, accounts need to be cleared, so it is necessary to manually change the credit of the original message to the transition account (999) and process the original message on the ground. Then click Return to generate a refund message with a debit of 999 according to the standard of (2).

4. If it is necessary to collect remittance refund fees, the system supports automatic configuration of fee rules and manual fee collection. Auto-provisioning charges follow Asia-Pacific Europe-Africa rules. Manual fee collection: Add a record in the Fee Tab page, select Fee Type, Fee Formula, fill in the fee amount, fee currency, and check "Suppress system fees". GUPP will no longer calculate the fee according to the fee rules during the processing , and only charge against the added fee entry. If the amount to be refunded is different from the original reported amount due to expenses or other business reasons, you can manually modify the amount in the refund report.

5. For the refund message initiated by GUPP, if the debit account is a local clearing account, no debit authorization check will be performed: including the refund transaction generated by clicking the RETURN button and the refund message manually created on the CL interface, if the debit is a local clearing account, No debit authorization checks are performed.

6. Regarding the withdrawal of received PI/SN messages, all SN messages cannot be returned by clicking the RETURN/REJECT button regardless of whether they have been matched successfully, that is, SN messages do not have a RETURN/REJECT button. If the matching is not successful, the PI message in the PAYSET state cannot be returned by clicking the RETURN/REJECT button. In this state, the PI message does not have a RETURN/REJECT button. Only the PI messages that have been successfully matched can be returned by clicking the RETURN/REJECT button.

For the received SN message, if the PI phone is not successfully matched, the remittance will be refunded by manually creating MTn96/MTn99/MT202, and the account will be adjusted manually.

7. According to the different accounting status before the APPROVE_CANCEL state of the original message, the teller needs to process the message accordingly, and then initiate the refund message. The following details the original report processing method and account processing:

(1) The original message APPROVE_CANCEL state has been successfully billed before. Click the Return button, and the sending page of the refund message will pop up, and the page will automatically display the debit account (the original message credit account), the credit account (the original message debit account), 72 field refund signs,

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

After the Verify operation, the packet undergoes subsequent processing, and the packet is Complete after processing.

Posting accounting entries are:

Dr: original message credit account number;

Cr: 8321;

Dr: 8321;

Cr: Debit account of the original message;

After the return message is processed, the status of the original message becomes Returned, and the original message and the return message can be linked to each other.

(2) The state before APPROVE_CANCEL of the original message is not Complete, and the debit has already charged.

After initiating the refund message, manually select the debit account of the refund message as the debit account of the original message (8341), confirm that the message information is correct, click Submit, submit the message, and the message status changes to Verify. After the Verify operation, the packet undergoes subsequent processing, and the packet is Complete after processing. Posting accounting entries are:

Dr: 8341;

Cr: 8321;

Dr: 8321;

Cr: credit account number of refund message;

After the return message is processed, the status of the original message becomes Returned, and the original message and the return message can be linked to each other.

(3) The state of the original message before APPROVE_CANCEL is not Complete, and no accounting processing has been done, and the channel of the original message is local settlement. In this scenario, accounts need to be settled, so it is necessary to manually change the lender of the original message to transition account (999), process the original message on the ground, and then refer to step (1), Return initiates a refund message with a debit of 999. Initiate a refund after the message is processed.

The Posting entry for the return report is:

Dr: 999 or special account for remittance refund;

Cr: 8321;

Dr: 8321;

Cr: Debit account of the original message.

In summary, after the GUPP system receives the remittance refund transaction, the system completes the following functions:

1. Identification of remittance refund transactions;

2. Matching of remittance refund transaction and original declaration;

3. Subsequent processing of remittance refund transactions and original declarations.

The core module of the embodiment of the present invention is to formulate a flexible and configurable revocation and remittance processing flow. Design a unified revocation and remittance processing process, and a flexible and configurable revocation and remittance processing mechanism.

The embodiment of the present invention can flexibly respond to the revocation and remittance refund requirements proposed by the branch, and can realize various changes in revocation and remittance refund business scenarios without modifying the system code. This not only expands the system function, but also improves the flexibility and configurability of the system.

Embodiments of the present invention also provide a flexible and configurable transaction refund processing system, as described in the following embodiments. Since the problem-solving principle of this system is similar to the flexible and configurable transaction refund processing method, the implementation of this system can refer to the implementation of the flexible and configurable transaction refund processing method, and the repetition will not be repeated.

Fig. 5 is a schematic structural diagram of a flexible and configurable transaction refund processing system in an embodiment of the present invention. As shown in Fig. 5, the system includes:

The first financial institution 01 is configured to send a revocation message for the current transaction to the second financial institution when it recognizes that the current transaction is a remittance transaction to be refunded;

The second financial institution 02 is used to determine 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 pre-configured business requirement scenario and the transaction refund processing strategy. The transaction refund processing strategy is to send the refund message to the first financial institution.

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

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, determine the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction: SWIFT, SWIFTFinCopy, local clearing proprietary The revocation of the format payment message and the remittance refund processing strategy, according to the transaction remittance processing strategy, send the remittance refund message to the first financial institution.

In one embodiment, the revocation and remittance processing strategies of SWIFT, SWIFTFinCopy, and local clearing proprietary format payment messages include:

Automatically match the refund message with the original message;

Return packets that fail to be automatically matched will enter the ROFi queue, and the original packets that meet the preset manual matching rules will be screened out for business personnel to manually select and match;

If both automatic matching and manual matching fail, find the message that needs to be processed from the return message queue;

When automatically processing the refund message received in the remittance scenario, determine the number of times the message will be finally sent to the original message sending bank.

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

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, determine the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction: Pacs008 for G3BULK inward and outward transactions , the remittance refund processing strategy of the Pacs003 message, according to the remittance refund processing strategy, the remittance refund message is sent to the first financial institution;

Or, according to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: The file type is Pacs004, MT103, MT202, CHIPS, FED refund message policy, and send the refund message to the first financial institution;

Or, according to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: The original payment message is matched in the revocation message, and the policy of generating a remittance refund message associated with the original payment message according to the original payment message is sent to the first financial institution.

In one embodiment, the Pacs008 and Pacs003 messages of the G3BULK import and export transaction have a refund processing policy, or the message type is Pacs004, MT103, MT202, CHIPS, and FED, or match from the cancel message Generate the original payment message, and generate a refund message associated with the original payment message for the original payment message, including:

Automatically match the refund message with the original message according to the preset rules;

After the automatic matching is successful, the return message needs to be linked to the original message, and the 21 fields of the AFTER message of the return message are equal to the original 20 fields of the original message;

If it is a remittance transfer, the receiving line of the return message should be equal to the first effective debit of the original message, and the After message complies with the preset mapping rules;

If both automatic matching and manual matching fail, find the message that needs to be processed from the return message queue;

If you receive a Pacs009 non-standard refund message from the upline bank whose debit MOP is INTERO, this kind of message is not supported to enter the refund process, and such messages need to be processed manually.

An embodiment of the present invention also provides a computer device, including a memory, a processor, and a computer program stored on the memory and operable on the processor. When the processor executes the computer program, the above-mentioned flexible and configurable transaction refund sink processing method.

An embodiment of the present invention also provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned flexible and configurable transaction refund processing method is realized.

An embodiment of the present invention also provides a computer program product, the computer program product includes a computer program, and when the computer program is executed by a processor, the above-mentioned flexible and configurable transaction refund processing method is realized.

In the embodiment of the present invention, the flexible and configurable transaction refund processing scheme is through: when the first financial institution recognizes that the current transaction is a transaction to be refunded, it sends a cancellation message to the second financial institution for the current transaction; the second financial institution According to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction, and according to the transaction refund processing strategy Generate a refund report, and send the refund report to the first financial institution. The present invention can flexibly respond to the revocation and remittance refund requirements proposed by the branch, and can realize various changes in revocation and remittance refund business scenarios without modifying the system code, thereby not only expanding the system function, but also improving the flexible configurability of the system .

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

The specific embodiments described above have further described the purpose, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above descriptions are only specific embodiments of the present invention and are not intended to limit the scope of the present invention. Protection scope, within the spirit and principles of the present invention, any modification, equivalent replacement, improvement, etc., shall be included in the protection scope of the present invention.

Claims (13)

1. A flexible and configurable transaction refund processing method, characterized in that it includes: When the first financial institution recognizes that the current transaction is a transaction to be refunded, it sends a cancellation message to the second financial institution for 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 refund processing strategy, the second financial institution determines the transaction refund processing strategy corresponding to the business demand scenario of the current transaction. The remittance processing strategy is used to send the remittance refund message to the first financial institution. 2. The flexible and configurable transaction refund processing method according to claim 1, characterized in that the second financial institution is based on the business demand scenario of the current transaction, and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy relationship, determine the transaction refund processing strategy corresponding to the business demand scenario of the current transaction, and send the refund message to the first financial institution according to the transaction refund processing strategy, including: According to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: SWIFT, SWIFTFinCopy, The revocation and remittance processing strategy of the payment message in the local clearing proprietary format, according to the transaction remittance processing strategy, sends the remittance message to the first financial institution. 3. The flexible and configurable transaction refund processing method according to claim 2, characterized in that the revocation and refund processing strategies of SWIFT, SWIFFTFinCopy, and local clearing proprietary format payment messages include: Automatically match the refund message with the original message; Return packets that fail to be automatically matched will enter the ROFi queue, and the original packets that meet the preset manual matching rules will be screened out for business personnel to manually select and match; If both automatic matching and manual matching fail, find the message that needs to be processed from the return message queue; When automatically processing the refund message received in the remittance scenario, determine the number of times the message will be finally sent to the original message sending bank. 4. The flexible and configurable transaction refund processing method according to claim 1, characterized in that, the second financial institution is based on the business demand scenario of the current transaction, and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy relationship, determine the transaction refund processing strategy corresponding to the business demand scenario of the current transaction, and send the refund message to the first financial institution according to the transaction refund processing strategy, including: According to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: G3BULK Inward Remittance The remittance processing policy of the Pacs008 and Pacs003 messages of the transaction, according to the remittance processing strategy, the remittance message is sent to the first financial institution; Or, according to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: The file type is Pacs004, MT103, MT202, CHIPS, FED refund message policy, and send the refund message to the first financial institution; Or, according to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: The original payment message is matched in the revocation message, and the policy of generating a remittance refund message associated with the original payment message according to the original payment message is sent to the first financial institution. 5. The flexible and configurable transaction remittance processing method according to claim 4, characterized in that, the remittance processing strategy of the Pacs008 and Pacs003 messages of G3BULK remittance and remittance transactions, or the message types are Pacs004, MT103, MT202, CHIPS, FED refund message policy, or match the original payment message from the revocation message, and generate a refund message associated with the original payment message for the original payment message, including: Automatically match the refund message with the original message according to the preset rules; After the automatic matching is successful, the return message needs to be linked to the original message, and the 21 fields of the AFTER message of the return message are equal to the original 20 fields of the original message; If it is a remittance transfer, the receiving line of the return message should be equal to the first effective debit of the original message, and the After message complies with the preset mapping rules; If both automatic matching and manual matching fail, find the message that needs to be processed from the return message queue; If you receive a Pacs009 non-standard refund message from the upline bank whose debit MOP is INTERO, this kind of message is not supported to enter the refund process, and such messages need to be processed manually. 6. A flexible and configurable transaction refund processing system, characterized in that it includes: The first financial institution is configured to send a revocation message for the current transaction to the second financial institution when identifying that the current transaction is a transaction to be refunded; The second financial institution is used to determine 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 pre-configured business requirement scenario and the transaction refund processing strategy. According to the above-mentioned transaction refund processing strategy, the refund message is sent to the first financial institution. 7. The flexible and configurable transaction refund processing system according to claim 6, wherein the second financial institution is specifically used for: 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, determine the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction: SWIFT, SWIFTFinCopy, local clearing proprietary The revocation of the format payment message and the remittance refund processing strategy, according to the transaction remittance processing strategy, send the remittance refund message to the first financial institution. 8. The flexible and configurable transaction refund processing system according to claim 7, characterized in that the revocation and refund processing strategies of SWIFT, SWIFFTFinCopy, and local clearing proprietary format payment messages include: Automatically match the refund message with the original message; Return packets that fail to be automatically matched will enter the ROFi queue, and the original packets that meet the preset manual matching rules will be screened out for business personnel to manually select and match; If both automatic matching and manual matching fail, find the message that needs to be processed from the return message queue; When automatically processing the refund message received in the remittance scenario, determine the number of times the message will be finally sent to the original message sending bank. 9. The flexible and configurable transaction refund processing system according to claim 6, wherein the second financial institution is specifically used for: 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, determine the transaction refund processing strategy corresponding to the business requirement scenario of the current transaction: Pacs008 for G3BULK inward and outward transactions , the remittance refund processing strategy of the Pacs003 message, according to the remittance refund processing strategy, the remittance refund message is sent to the first financial institution; Or, according to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: The file type is Pacs004, MT103, MT202, CHIPS, FED refund message policy, and send the refund message to the first financial institution; Or, according to the business demand scenario of the current transaction and the relationship between the pre-configured business demand scenario and the transaction refund processing strategy, the second financial institution determines that the transaction refund processing strategy corresponding to the business demand scenario of the current transaction is: The original payment message is matched in the revocation message, and the policy of generating a remittance refund message associated with the original payment message according to the original payment message is sent to the first financial institution. 10. The flexible and configurable transaction refund processing system as claimed in claim 9, characterized in that, the Pacs008 and Pacs003 messages of the G3BULK remittance and remittance transactions have a refund processing strategy, or the message types are Pacs004, MT103, MT202, CHIPS, FED refund message policy, or match the original payment message from the revocation message, and generate a refund message associated with the original payment message for the original payment message, including: Automatically match the refund message with the original message according to the preset rules; After the automatic matching is successful, the return message needs to be linked to the original message, and the 21 fields of the AFTER message of the return message are equal to the original 20 fields of the original message; If it is a remittance transfer, the receiving line of the return message should be equal to the first effective debit of the original message, and the After message complies with the preset mapping rules; If both automatic matching and manual matching fail, find the message that needs to be processed from the return message queue; If you receive a Pacs009 non-standard refund message from the upline bank whose debit MOP is INTERO, this kind of message is not supported to enter the refund process, and such messages need to be processed manually. 11. A computer device, comprising a memory, a processor, and a computer program stored on the memory and operable on the processor, characterized in that, when the processor executes the computer program, any one of claims 1 to 5 is realized. the method. 12. A computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented. 13. A computer program product, characterized in that the computer program product comprises a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 5 is realized.

Images