CN114785875B - Message processing method and system - Google Patents
Message processing method and system Download PDFInfo
- Publication number
- CN114785875B CN114785875B CN202210348155.9A CN202210348155A CN114785875B CN 114785875 B CN114785875 B CN 114785875B CN 202210348155 A CN202210348155 A CN 202210348155A CN 114785875 B CN114785875 B CN 114785875B
- Authority
- CN
- China
- Prior art keywords
- instruction
- message
- request
- revocation
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention relates to a message processing method and a system, wherein the method comprises the following steps: receiving a first message, and obtaining the type of the first message, wherein the type comprises a request message and a revocation message; if the type of the first message is a revocation message, extracting a revocation instruction list from the revocation message, analyzing each revocation instruction in the revocation instruction list to perform corresponding processing, and generating processing feedback information; if the type of the first message is a request message, extracting a request instruction list from the request message, and marking all the request instructions in the request instruction list as unprocessed states; circularly reading and analyzing each request instruction in the request instruction list to perform corresponding processing, and generating processing feedback information; generating reply information based on the processing feedback information; wherein the revocation instruction is associated with a request instruction. Compared with the prior art, the invention has the advantages of improving efficiency and the like.
Description
Technical Field
The invention belongs to the technical field of financial data processing, and particularly relates to a message processing method and system.
Background
With the progress of globalization of world economy, funding between countries around the world frequently occurs. In order to provide high-quality and rapid global remittance service for clients, each bank joins in a financial settlement network organization in a dispute, funds remittance information is transferred through a special network, and the whole special transmission network of the financial information is connected with an IT processing system of each bank to form a special network of the global financial information for financial information transmission. The world bank financial communication association (Society For Worldwide Interbank Financial Telecommunication s.c., SWIFT) is an international cooperative organization of non-profitability between international banking peers through which banks and other financial institutions exchange messages with peers to complete financial transactions.
The financial transfer messages typically include information such as sender bank, recipient bank information, money transfer currency, money transfer amount, etc., sender and receiver information, etc. Because the country where the sender and the receiver are located is different, there often occurs a case where a currency exchange is required, that is, the currency of the remittance is exchanged into a local currency by a bank where the receiver is located through a foreign exchange purchase. Because the remittance business involves banks of the remittance party and the receiving party, the financial settlement message information needs a certain time to be transmitted on the network, and the process needs a certain manual judgment and processing to influence the efficiency.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provide a message processing method and a system with high efficiency.
The aim of the invention can be achieved by the following technical scheme:
a message processing method comprises the following steps:
receiving a first message, and obtaining the type of the first message, wherein the type comprises a request message and a revocation message;
if the type of the first message is a revocation message, extracting a revocation instruction list from the revocation message, analyzing each revocation instruction in the revocation instruction list to perform corresponding processing, and generating processing feedback information;
if the type of the first message is a request message, extracting a request instruction list from the request message, and marking all the request instructions in the request instruction list as unprocessed states;
circularly reading and analyzing each request instruction in the request instruction list to perform corresponding processing, and generating processing feedback information;
generating reply information based on the processing feedback information;
wherein the revocation instruction is associated with a request instruction.
Further, the request message includes a transfer request message and a direct debit request message.
Further, the content of the request message comprises a file header part and an instruction part, wherein the file header part comprises a message ID, an enterprise BIC and a reserved execution date, the instruction part comprises at least one request instruction, and each instruction has a unique instruction ID;
the content of the revocation message comprises a file header part and an instruction part, wherein the file header part comprises a message ID, an enterprise BIC and a reserved execution date, and the instruction part only comprises one revocation instruction.
Further, the analyzing each revocation instruction in the revocation instruction list table to perform corresponding processing specifically includes:
acquiring a revocation instruction, searching whether a request instruction corresponding to the revocation instruction exists, if so, acquiring the state of the request instruction, correspondingly updating the state of the revocation instruction according to the state of the request instruction, generating processing feedback information, and if not, exiting.
Further, the updating the state of the revocation instruction according to the state of the request instruction specifically includes:
if the state of the request instruction is successful in checking in, the method is easy to process in a flushing orthogonal mode, the state of the update request instruction is successful in flushing in a flushing mode, and the state of the update withdrawal instruction is processed;
if the state of the request instruction is the check-in failure or the request instruction is cancelled, updating the state of the cancellation instruction to be processed;
if the state of the request instruction is unprocessed, the state of the update request instruction is cancelled, and the state of the update cancellation instruction is processed.
Further, the corresponding processing of each request instruction is specifically:
and acquiring a request instruction which is unprocessed and has reached the reserved execution date, searching whether a revocation instruction with the request instruction exists, if so, updating the state of the request instruction, and if not, performing accounting processing, and updating the state of the request instruction to be successful or failed according to the processing result.
Further, the association of the revocation instruction and the request instruction is realized through a message ID, an instruction ID and an enterprise BIC.
The invention also provides a message processing system, which comprises:
the receiving module is used for receiving a first message and acquiring the type of the first message, wherein the type comprises a request message and a withdrawal message;
the revocation processing module is used for responding when the type of the first message is a revocation message, extracting a revocation instruction list from the revocation message, analyzing each revocation instruction in the revocation instruction list to perform corresponding processing, and generating processing feedback information;
the request processing module responds when the type of the first message is a request message, extracts a request instruction list from the request message, and marks all request instructions in the request instruction list as unprocessed states;
the request instruction processing module is in a continuous running state, circularly reads and analyzes each request instruction in the request instruction list to perform corresponding processing, and generates processing feedback information;
the reply module is used for generating reply information based on the processing feedback information;
wherein the revocation instruction is associated with a request instruction.
Further, the reply module includes:
the revocation recovery unit responds after obtaining the update of the state of the revocation instruction and is used for sending the latest state of the revocation instruction;
and the request replying unit responds after acquiring the update of the state of the request instruction and is used for sending the latest state of the request instruction.
The present invention also provides a computer readable storage medium comprising one or more programs for execution by one or more processors of an electronic device, the one or more programs comprising instructions for performing the message processing method as described above.
Compared with the prior art, the invention has the following beneficial effects:
the invention designs an automatic processing flow of the request message and the withdrawal message, corresponding processing is automatically executed through different states of the instruction, and the request instruction processing module is in a continuous running state, so that each instruction can be processed in time, the payment, withdrawal or positive flushing efficiency is effectively improved, the method is convenient and quick, and enterprises do not need to be in a clinic.
Drawings
FIG. 1 is a schematic flow chart of the present invention.
Detailed Description
The invention will now be described in detail with reference to the drawings and specific examples. The present embodiment is implemented on the premise of the technical scheme of the present invention, and a detailed implementation manner and a specific operation process are given, but the protection scope of the present invention is not limited to the following examples.
As shown in fig. 1, the present invention provides a message processing method, which includes the following steps:
receiving a first message, and obtaining the type of the first message, wherein the type comprises a request message and a revocation message;
if the type of the first message is a revocation message, extracting a revocation instruction list from the revocation message, analyzing each revocation instruction in the revocation instruction list to perform corresponding processing, and generating processing feedback information;
if the type of the first message is a request message, extracting a request instruction list from the request message, and marking all the request instructions in the request instruction list as unprocessed states;
circularly reading and analyzing each request instruction in the request instruction list to perform corresponding processing, and generating processing feedback information;
and generating reply information based on the processing feedback information.
The content of the request message comprises a file header part and an instruction part, wherein the file header part comprises a message ID, an enterprise BIC and a reserved execution date, the instruction part comprises at least one request instruction, and each instruction has a unique instruction ID; the content of the revocation message comprises a file header part and an instruction part, wherein the file header part comprises a message ID, an enterprise BIC and a reserved execution date, and the instruction part only comprises one revocation instruction. The association of the revocation instruction and the request instruction is realized through a message ID, an instruction ID and an enterprise BIC.
The request messages which can be processed by the method comprise a transfer request message and a direct debit request message. The method can process each instruction in time, effectively improves the payment, withdrawal or correction efficiency, is convenient and quick, and does not need a cabinet for enterprises.
The above-described method, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
In another embodiment, the above processing procedure may be implemented by a message processing system, where the message processing system includes a receipt module, a revocation processing module, a request instruction processing module, and a reply module, where:
the receiving module is used for receiving a first message and obtaining the type of the first message, wherein the type comprises a request message and a withdrawal message;
the revocation processing module responds when the type of the first message is a revocation message, extracts a revocation instruction list from the revocation message, analyzes each revocation instruction in the revocation instruction list to perform corresponding processing, and generates processing feedback information;
the request processing module responds when the type of the first message is a request message, extracts a request instruction list from the request message and marks all request instructions in the request instruction list as unprocessed states;
the request instruction processing module is in a continuous running state, circularly reads and analyzes each request instruction in the request instruction list to perform corresponding processing, and generates processing feedback information;
the reply module generates reply information based on the processing feedback information, and the reply module comprises: the revocation recovery unit responds after obtaining the update of the state of the revocation instruction and is used for sending the latest state of the revocation instruction; and the request replying unit responds after acquiring the update of the state of the request instruction and is used for sending the latest state of the request instruction.
Example 1
The embodiment performs online processing on the transfer request message based on a message processing system.
Interpretation of the terms
SWIFT network: the global banking and financial telecommunication association (Society For Worldwide Interbank Financial Telecommunication s.c., SWIFT) is an international organization for the co-operation of non-profitability between international banking. SWIFT operates a worldwide financial messaging network through which banks and other financial institutions exchange messages with the same industry to complete financial transactions.
MT101: the transfer request message is typically sent by the corporation to an opening bank or an agent bank, where the money is drawn to a recipient designated by the message. One MT101 message may contain multiple transaction requests.
MT192: the revocation request message is initiated by the primary packet party, and this patent refers to the associated MT101 message initiator. After the corporation sends MT101, if a payment request (single pass) needs to be revoked, MT192 may be sent to instruct the bank to revoke the transaction.
MT199: and (3) a state reply message of the MT101 payment instruction, wherein each MT199 message corresponds to one MT101 payment instruction and is generated and sent by a bank end.
MT196: and generating and transmitting a response message of the MT192 revocation message by a bank end.
And (3) correcting: if the bank receives the MT101 message, the payment request is processed, i.e. the payment request is checked in. The bank makes a reverse transaction and the deposit amount is returned to the payment account.
BIC: the SWIFT bank identification code, the unit of each application added into SWIFT organization must be in advance according to the unified rule of SWIFT organization, the SWIFT address code of the present line is made, and the SWIFT organization is approved and formally effective.
The usage scenario of the message processing system of this embodiment is: after the enterprise sends the MT101 payment request through the SWIFT network, if the associated MT192 message needs to be withdrawn, the bank can send the associated MT192 message to the bank, the bank is associated with the original MT101 payment request according to the 21 fields and the 79 fields of the MT192 message, and the withdrawal (before the posting) and the flushing (before the posting) are carried out according to the current processing condition. If the MT101 instruction state changes, the bank timely returns an MT199 state message to the enterprise. After the MT192 receives or processes, the bank timely returns an MT196 reply message to the enterprise. The system can cancel or flush payment instructions in a plurality of scenes such as MT101 arriving at MT192 first and then arriving at MT101, MT101 instruction is checked in, MT101 instruction is not checked in and the like. And returning MT199 state messages to the enterprise in real time according to the transition of the MT101 payment instruction state; and informs the enterprise of the revocation message status after receiving or processing the MT192 message.
MT101 is like, for example, the following:
in this embodiment, the MT101 includes a header and a message detail, where the field of the header 20 is the ID number of the message, and each message is different. The message detail 21 field is a payment ID number, and each payment instruction is different. In the sample, there are 2 21 fields of messages, namely, two payment instructions.
The content of the file header part is as follows:
20 field-message ID-0000013043
28 field-message nth packet/total packet number (subpackage, 1 packet for sample, 1/1)
50 field-Payment Account 100200700213638 and Payment name
52 field-payline BIC-BKCHDEBJ44W
30 field-appointment execution date 190401, namely 2019, 4, 1
Payment instruction 1:
21 field-Payment order ID-0000013485
32 field-pay amount $ 13.02
57 field-receipts line BIC-BKCHDEFF
59 field-collection account number 100200700215206 and name
71A: fee-bearing mode-common bearing by payees
Payment instruction 2:
21 field-Payment order ID-0000013486
32 field-payment amount 14 yen
57 field-receipts line BIC-BKCHCNBJ
59 field-collection account number 100200700218412 and name
71A: fee-bearing mode-common bearing by payees
MT 192-like for example the following:
the field 20 of the message is the ID number of the message, and each message is different. The 21 fields are 20 fields of the associated MT101 message. The first and second rows of 11S are 30 fields of associated message types 101 and 101 messages, respectively, i.e., the reservation date. 79 fields are associated MT101 message detail 21 fields, and each MT192 message can only withdraw one payment request.
20 field-message ID-0000013765
21 field-associated MT101 message ID0000013043
11S first line: the associated message type is 101
11S second line: 30 fields of the associated MT101 message are 190401 (i.e. 1 day of 2019, 4 months)
79 fields: associated MT101 Payment order ID0000013485
MT199 is like, for example, the following:
the field of the header 20 is the ID number of the message, and each message is different. 21 fields of the 21-field original MT101 message. 79 head behavior states (ACSC-checked-in, RJCT-not checked-in, ACCR-revocation request has been processed, i.e. not checked-in), follow-up behavior processing instructions.
MT196 is like, for example, the following:
the field of the header 20 is the ID number of the message, and each message is different. 20 fields of a 21 field associated MT192 message. The 76 fields are state descriptions (RCVD-received, ACCP-processed).
In this embodiment, the specific functions of each module of the message processing system are as follows:
and the message receiving module S0 is used for splitting the message type from the fixed message position after receiving the message. In particular embodiments, it may be determined based on the text box bold portion 101 or 192 and the sender, i.e., business BIC (CRESCHZF). And respectively calling a revocation processing module S1 or a request processing module S2 according to the message type.
The process module S1 is withdrawn, the 21 field/11S field/79 field is split, and the MT192 instruction list (state RCVD) is recorded. And searches corresponding MT101 instructions from the MT101 instruction list according to 21 fields, 11S, enterprise BIC and 79 fields in the instructions. If found and MT101 state is successful in posting (ACSC), then the backstage flushing orthogonal easy is called, and MT101 instruction is updated to be successful in flushing (ACCR), MT192 state is processed (ACCP); if found and the status is check-in failure (RJCT) or revoked (ACSC), updating MT192 status to processed (ACCP); if found and the state is unprocessed, updating MT101 instruction state to revoke (ACCR), MT192 state to processed (ACCP); if not, exit. The MT101 needs to call a request replying unit S4 if the instruction state changes; MT192 cancels the message and calls to cancel replying unit S5 when it is received or processed.
The request processing module S2 splits the file header and the file detail, and records the MT101 instruction detail list, and the split detail state is to be processed.
The request instruction processing module S3, which is a resident daemon. The process circularly reads all MT101 payment instructions which are unprocessed and have the system date < = 30 fields of the message from the MT101 instruction list, namely the reservation date is reached, and searches corresponding 192 instructions from the MT192 instruction list according to 20 fields, 21 fields, 30 fields and enterprise BIC in the instructions. If found, update MT101 instruction state to revoke (ACCR), MT192 instruction state to processed (ACCP); if not, the corresponding accounting interface is called to perform accounting processing, and the MT101 instruction state is set to be successful (ACSC) or failed (RJCT) according to the background return state. The MT101 needs to call a request replying unit S4 if the instruction state changes; MT192 has processed it calls the revocation reply unit S5.
The request replying unit S4 generates 199 a message according to the updated state ACCR, ACSC or RJCT of the MT101, and then sends the message to the enterprise.
And the revocation recovery unit S5 generates 196 a message according to the updated state RCVD and ACCP of the MT192 and sends the message to the enterprise.
Example 2
The present embodiment is based on a message processing system performing on-line processing of direct debit request messages.
Interpretation of the terms
MT104: the request message is debited directly. One MT104 message may contain multiple collection instructions.
The bank pays money directly from the payer account according to the contract (agreement) and transfers the money to the collection account of the enterprise. The payment account may be a receipts bank principal account or other line account. The enterprise needs to sign up with the bank to delegate the agreement.
MT192: the revocation request message is initiated by the primary packet party, and this patent refers to the associated MT104 message initiator. After the enterprise sends the MT104, if the collection request needs to be cancelled (single transaction), the MT192 may be sent to instruct the bank to cancel the transaction.
MT199: and (3) responding to the state of the MT104 collection instruction, wherein each MT199 message corresponds to one MT104 collection instruction, and the MT104 collection instruction is generated and sent by a bank end.
MT196: and generating and transmitting a response message of the MT192 revocation message by a bank end.
And (3) correcting: if the bank receives the MT104 message, the receipt request is processed, i.e. the receipt is checked in. The bank makes a reverse transaction and the deposit amount is returned to the payment account.
The usage scenario of the message processing system of this embodiment is: after the enterprise sends the MT104 direct debit (collection) request through the SWIFT network, if the associated MT192 message needs to be withdrawn, the bank can send the associated MT192 message to the bank, the bank associates the MT192 message 21 field with the original MT104 collection request, and the withdrawal (before the billing) and the flushing (the billing) are carried out according to the current processing condition. The MT104 instructs the state to change, and the bank returns an MT199 state message to the enterprise in time. After the MT192 receives or processes, the bank timely returns an MT196 reply message to the enterprise. The system can cancel or flush the collection instruction under a plurality of scenes such as the MT104 arrives at the MT192 first and then arrives at the MT104, the MT104 instruction is checked in, the MT104 instruction is not checked in and the like. And return MT199 state message to enterprise in real time according to transition of MT104 collection instruction state; and informs the enterprise of the revocation message status after receiving or processing the MT192 message.
MT104 like for example the following:
in this embodiment, the MT104 includes a header and a message detail, where the field of the header 20 is the ID number of the message, and each message is different. The message detail 21 is a collection ID number, and each collection instruction is different. In the sample, 2 messages are sent to 21 fields, namely, two collection instructions are provided.
The content of the file header part is as follows:
20 field-message ID T300164800
30 field-appointment execution date 190401, namely 2019, 4, 1
50 field-Cash Account 325956086490 and Cash name
52 field-receipts line number-104100000045 and name
Collection instruction 1:
21-field-receipt ID-T300164801
32 money-collection amount 2.00 RMB
57 field-Payment line number 105301000013
59 field-Payment Account 778350120134 and name
70 fields: appendix of the invention
Collection instruction 2:
21-field-receipt ID-T300164802
32-money collection amount 60000 RMB
57 field-Payment line number 105301000013
59 field-Payment Account 778350120178 and name
70 fields: appendix of the invention
MT 192-like for example the following:
the field 20 of the message is the ID number of the message, and each message is different. The 21 fields are 20 fields of the associated MT104 message. The first and second lines of 11S are 30 fields of associated message types 104 and 104 messages, respectively, i.e., the reservation date. 79 fields are associated MT104 message detail 21 fields, and each MT192 message can only withdraw one collection request.
20 field-message ID0000013765
21-field-associated MT104 deposit message ID-T300164800
11S first line: the associated message type is 104
11S second line: 30 fields of the associated MT104 message are 190401 (namely, 2019, 4, 1)
79 fields: associated MT104 collection instruction ID-T300164801
MT199 is like, for example, the following:
the field of the header 20 is the ID number of the message, and each message is different. 21 fields of the 21-field original MT104 message. 79 head behavior states (ACSC-checked-in, RJCT-not checked-in, ACCR-revocation request has been processed, i.e. not checked-in), follow-up behavior processing instructions.
MT196 is like, for example, the following:
the field of the header 20 is the ID number of the message, and each message is different. 20 fields of a 21 field associated MT192 message. The 76 fields are state descriptions (RCVD-received, ACCP-processed).
In this embodiment, the specific functions of each module of the message processing system are as follows:
the receiving module S0, after receiving the message, splits the message type (text box bold portion 104 or 192 and sender, i.e. enterprise BIC (CRESCHZF)) from the message fixed location, and calls the revocation processing module S1 or the request processing module S2, respectively, according to the message type.
The process module S1 is withdrawn, the 21 field/11S field/79 field is split, and the MT192 instruction list (state RCVD) is recorded. And looks up the corresponding MT104 instruction from the MT104 instruction list according to the 21 field, 11S, enterprise BIC, 79 field in the instruction. If found and MT104 state is successful in posting (ACSC), then call the background flush orthogonal easy, and update MT104 instruction as successful in flushing (ACCR), MT192 state as processed (ACCP); if found and the status is check-in failure (RJCT) or revoked (ACSC), updating MT192 status to processed (ACCP); if found and the state is unprocessed, updating MT104 instruction state to revoke (ACCR), MT192 state to processed (ACCP); if not, exit. The MT104 needs to call a request replying unit S4 if the instruction state changes; MT192 cancels the message and calls to cancel replying unit S5 when it is received or processed.
The request processing module S2 splits the file header and the file detail, and records the MT104 instruction detail list, and the split detail state is to be processed.
The request instruction processing module S3, which is a resident daemon. The process circularly reads all MT104 collection instructions which are unprocessed and have the system date < = 30 fields of messages from the MT104 instruction list, namely the reservation date is reached, and searches corresponding 192 instructions from the MT192 instruction list according to 20 fields, 21 fields, 30 fields and enterprise BIC in the instructions. If found, update MT104 instruction state to revoked (ACCR), MT192 instruction state to processed (ACCP); if not, the corresponding accounting interface is called to perform accounting processing, and the MT104 instruction state is set to be successful (ACSC) or failed (RJCT) according to the background return state. The MT104 needs to call a request replying unit S4 if the instruction state changes; MT192 has processed it calls the revocation reply unit S5.
The request replying unit S4 generates 199 a message according to the updated state ACCR, ACSC or RJCT of the MT104, and then sends the message to the enterprise.
And the revocation recovery unit S5 generates 196 a message according to the updated state RCVD and ACCP of the MT192 and sends the message to the enterprise.
The foregoing describes in detail preferred embodiments of the present invention. It should be understood that numerous modifications and variations can be made in accordance with the concepts of the invention by one of ordinary skill in the art without undue burden. Therefore, all technical solutions which can be obtained by logic analysis, reasoning or limited experiments based on the prior art by the person skilled in the art according to the inventive concept shall be within the scope of protection defined by the claims.
Claims (6)
1. A method for processing a message, comprising the steps of:
receiving a first message, and obtaining the type of the first message, wherein the type comprises a request message and a revocation message;
if the type of the first message is a revocation message, extracting a revocation instruction list from the revocation message, analyzing each revocation instruction in the revocation instruction list, and correspondingly processing the revocation instructions to generate processing feedback information;
if the type of the first message is a request message, extracting a request instruction list from the request message, and marking all the request instructions in the request instruction list as unprocessed states;
circularly reading and analyzing each request instruction in the request instruction list and carrying out corresponding processing to generate processing feedback information;
generating reply information based on the processing feedback information;
the revocation instruction is associated with the request instruction, and specifically, the association is realized through a message ID, an instruction ID and an enterprise BIC;
the specific steps of analyzing each revocation instruction in the revocation instruction list and performing corresponding processing are as follows:
acquiring a revocation instruction, searching whether a request instruction corresponding to the revocation instruction exists, if so, acquiring the state of the request instruction, correspondingly updating the state of the revocation instruction according to the state of the request instruction, generating processing feedback information, and if not, exiting;
the state of the revocation instruction is updated correspondingly according to the state of the request instruction, specifically:
if the state of the request instruction is successful in checking in, the method is easy to process in a flushing orthogonal mode, the state of the update request instruction is successful in flushing in a flushing mode, and the state of the update withdrawal instruction is processed;
if the state of the request instruction is the check-in failure or the request instruction is cancelled, updating the state of the cancellation instruction to be processed;
if the state of the request instruction is unprocessed, updating the state of the request instruction to be cancelled, and updating the state of the cancellation instruction to be processed;
the corresponding processing of each request instruction is specifically as follows:
and acquiring a request instruction which is unprocessed and has reached the reserved execution date, searching whether a revocation instruction with the request instruction exists, if so, updating the state of the request instruction to be revoked, and meanwhile updating the state of the revocation instruction to be processed, if not, performing accounting processing, and updating the state of the request instruction to be successful or failed according to the processing result.
2. The message processing method according to claim 1, wherein the request message includes a transfer request message and a direct debit request message.
3. The message processing method according to claim 1, wherein the content of the request message includes a header portion and an instruction portion, the header portion including a message ID, an enterprise BIC, and a reservation execution date, the instruction portion including at least one request instruction, each instruction having a unique instruction ID;
the content of the revocation message comprises a file header part and an instruction part, wherein the file header part comprises a message ID, an enterprise BIC and a reserved execution date, and the instruction part only comprises one revocation instruction.
4. A message processing system, comprising:
the receiving module is used for receiving a first message and acquiring the type of the first message, wherein the type comprises a request message and a withdrawal message;
the revocation processing module is used for responding when the type of the first message is a revocation message, extracting a revocation instruction list from the revocation message, analyzing each revocation instruction in the revocation instruction list, and correspondingly processing the revocation instructions to generate processing feedback information;
the request processing module responds when the type of the first message is a request message, extracts a request instruction list from the request message, and marks all request instructions in the request instruction list as unprocessed states;
the request instruction processing module is in a continuous running state, circularly reads and analyzes each request instruction in the request instruction list and carries out corresponding processing to generate processing feedback information;
the reply module is used for generating reply information based on the processing feedback information;
the revocation instruction is associated with the request instruction, and specifically, the association is realized through a message ID, an instruction ID and an enterprise BIC;
the specific steps of analyzing each revocation instruction in the revocation instruction list and performing corresponding processing are as follows:
acquiring a revocation instruction, searching whether a request instruction corresponding to the revocation instruction exists, if so, acquiring the state of the request instruction, correspondingly updating the state of the revocation instruction according to the state of the request instruction, generating processing feedback information, and if not, exiting;
the state of the revocation instruction is updated correspondingly according to the state of the request instruction, specifically:
if the state of the request instruction is successful in checking in, the method is easy to process in a flushing orthogonal mode, the state of the update request instruction is successful in flushing in a flushing mode, and the state of the update withdrawal instruction is processed;
if the state of the request instruction is the check-in failure or the request instruction is cancelled, updating the state of the cancellation instruction to be processed;
if the state of the request instruction is unprocessed, updating the state of the request instruction to be cancelled, and updating the state of the cancellation instruction to be processed;
the corresponding processing of each request instruction is specifically as follows:
and acquiring a request instruction which is unprocessed and has reached the reserved execution date, searching whether a revocation instruction with the request instruction exists, if so, updating the state of the request instruction to be revoked, and meanwhile updating the state of the revocation instruction to be processed, if not, performing accounting processing, and updating the state of the request instruction to be successful or failed according to the processing result.
5. The message processing system of claim 4, wherein the reply module comprises:
the revocation recovery unit responds after obtaining the update of the state of the revocation instruction and is used for sending the latest state of the revocation instruction;
and the request replying unit responds after acquiring the update of the state of the request instruction and is used for sending the latest state of the request instruction.
6. A computer readable storage medium comprising one or more programs for execution by one or more processors of an electronic device, the one or more programs comprising instructions for performing the method of message processing of any of claims 1-3.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210348155.9A CN114785875B (en) | 2022-03-29 | 2022-03-29 | Message processing method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210348155.9A CN114785875B (en) | 2022-03-29 | 2022-03-29 | Message processing method and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114785875A CN114785875A (en) | 2022-07-22 |
| CN114785875B true CN114785875B (en) | 2024-02-23 |
Family
ID=82427424
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210348155.9A Active CN114785875B (en) | 2022-03-29 | 2022-03-29 | Message processing method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114785875B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115525328B (en) * | 2022-10-24 | 2025-12-12 | 中国银行股份有限公司 | Flexible and configurable transaction refund processing methods and systems |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101916421A (en) * | 2010-09-01 | 2010-12-15 | 中国建设银行股份有限公司 | Foreign exchange remittance service processing method and system |
| WO2016112675A1 (en) * | 2015-01-12 | 2016-07-21 | 广州广电运通金融电子股份有限公司 | Financial self-service system processing method |
| CN110519271A (en) * | 2019-08-28 | 2019-11-29 | 中国银行股份有限公司 | It can support the SWIFT message processing method and system of file transmission by all kinds of means |
| CN110896413A (en) * | 2019-11-18 | 2020-03-20 | 中国银行股份有限公司 | Message processing method and device |
| CN110910106A (en) * | 2019-11-29 | 2020-03-24 | 中国银行股份有限公司 | Cash management message processing method and system |
-
2022
- 2022-03-29 CN CN202210348155.9A patent/CN114785875B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101916421A (en) * | 2010-09-01 | 2010-12-15 | 中国建设银行股份有限公司 | Foreign exchange remittance service processing method and system |
| WO2016112675A1 (en) * | 2015-01-12 | 2016-07-21 | 广州广电运通金融电子股份有限公司 | Financial self-service system processing method |
| CN110519271A (en) * | 2019-08-28 | 2019-11-29 | 中国银行股份有限公司 | It can support the SWIFT message processing method and system of file transmission by all kinds of means |
| CN110896413A (en) * | 2019-11-18 | 2020-03-20 | 中国银行股份有限公司 | Message processing method and device |
| CN110910106A (en) * | 2019-11-29 | 2020-03-24 | 中国银行股份有限公司 | Cash management message processing method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114785875A (en) | 2022-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107103462B (en) | Method and device for processing snapshot data of cross-border remittance of bank | |
| CN110245930B (en) | System and method for paying customer bills using paymate of billing party | |
| AU2017356010A1 (en) | System and method for processing payment transactions at network edge nodes | |
| MX2013003317A (en) | Systems and methods for conducting a composite bill payment transaction. | |
| CN111275402B (en) | Processing method, system, equipment and medium for rapidly storing same-industry operation assembly line | |
| CN106101179B (en) | Resource processing method, device and system | |
| CN105427094A (en) | Cross-border payment system and method | |
| CN110276614A (en) | The update method and device of ledger | |
| JP2014081690A (en) | Overseas remittance system and overseas remittance method | |
| CN101916421A (en) | Foreign exchange remittance service processing method and system | |
| CN101877101A (en) | Bank payment system and operating method thereof | |
| US20160149918A1 (en) | Secure information interaction method for electronic resources transfer | |
| CN101393668A (en) | A transaction data processing method and system for arriving on the same day | |
| US20140236811A1 (en) | Efficient inter-bank funds transfers | |
| Islam et al. | Analysis of blockchain-based Ripple and SWIFT | |
| CN114785875B (en) | Message processing method and system | |
| JP6187947B1 (en) | Multi-bank pooling system and multi-bank pooling method | |
| CN110889682A (en) | Payment information processing method, device, medium and equipment based on block chain | |
| CN114529287A (en) | Service processing method and device, electronic equipment and computer readable medium | |
| CN115526722B (en) | Method and device for processing positive flushing transaction | |
| RU2761419C1 (en) | Method and system for transferring monetary funds from account to account | |
| CN115564420A (en) | Cross-border remittance processing method and device based on block chain | |
| KR20240167923A (en) | Preprocessing and validation of real-time data | |
| CN117061622A (en) | Message conversion method, device, equipment and storage medium | |
| US20070067238A1 (en) | System and method for transferring information between financial accounts |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |