Cross-border settlement message processing method and device, electronic equipment and storage medium

Abstract

The invention provides a cross-border settlement message processing method and device, electronic equipment and a storage medium, and the method comprises the steps: receiving a first message and determining a first message feature corresponding to the first message when receiving an incoming message initiation request, calling a first analysis rule matched with the first message from preset analysis rules, and carrying out the call of the first analysis rule from the preset analysis rules; mapping the first message field to a first service field to obtain a second message; then, whether transfer is needed or not is judged based on the service features, if transfer is needed, a second message feature is determined according to transfer information, then a matched second analysis rule is called, a second service field is mapped back to a second message field, and finally a third message serving as a transfer message is obtained; according to the invention, the matching analysis rule can be automatically called according to the message characteristics to complete message processing and transfer processing, and the cross-border settlement message processing efficiency and accuracy are improved.

Description

Technical Field

[0001] The present application relates to the field of payment and settlement technology, and in particular to a method, device, electronic device and storage medium for processing cross-border settlement messages. Background Art

[0002] In cross-border settlement transactions, after receiving the message from the remittance instructing bank, the account bank needs to draft a message to the final beneficiary bank based on the agreement and channel conditions agreed with the final beneficiary bank.

[0003] However, the channels used by account banks to process cross-border settlement funds include SWIFT, CFXPS (domestic and foreign currencies), CIPS (cross-border RMB), RTGS and many other channels. Each channel has corresponding clearing message technical standards, business applicability standards, processing time windows, etc., and the corresponding message channel must be determined based on the agreement with the beneficiary bank. Therefore, very careful selection and filling are required during the business processing process, which is inefficient. Summary of the Invention

[0004] In view of this, the embodiments of the present application provide a cross-border settlement message processing method, device, electronic device and storage medium, which can automatically call matching parsing rules according to message characteristics to complete message processing and remittance processing, thereby improving the efficiency and accuracy of cross-border settlement message processing.

[0005] The technical solution of the embodiment of the present application is implemented as follows: In a first aspect, an embodiment of the present application provides a method for processing a cross-border settlement message, the method comprising: In response to the incoming message initiation request, receiving a first message and determining a first message feature corresponding to the target message; Invoking a first parsing rule that matches the first message feature from preset parsing rules, and mapping a message field of the first message to a first service field based on the first parsing rule to obtain a second message; Determine whether remittance is required based on the business characteristics. If remittance is required, determine the second message characteristics based on the remittance information, call a second parsing rule that matches the second message characteristics from the preset parsing rules, and map the second business field to the message field of the second message based on the second parsing rule to obtain a third message; wherein the third message is a remittance message.

[0006] In a second aspect, an embodiment of the present application further provides a cross-border settlement message processing device, the device comprising: a determination module, configured to receive a first message in response to an incoming message initiation request, and determine a first message feature corresponding to the target message; a first mapping module, configured to call a first parsing rule that matches the first message feature from preset parsing rules, and map a message field of the first message to a first service field based on the first parsing rule to obtain a second message; The second mapping module is used to determine whether remittance is required based on the business characteristics. If remittance is required, the second message characteristics are determined according to the remittance information, a second parsing rule that matches the second message characteristics is called from the preset parsing rules, and the second business field is mapped to the message field of the second message based on the second parsing rule to obtain a third message; wherein the third message is a remittance message.

[0007] In a third aspect, an embodiment of the present application further provides an electronic device comprising: a processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the storage medium communicate through the bus, and the processor executes the machine-readable instructions to execute the cross-border settlement message processing method described in any one of the first aspects.

[0008] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the cross-border settlement message processing method described in any one of the first aspects is executed.

[0009] The embodiments of the present application have the following beneficial effects: Through a dynamic feature-driven message parsing and intelligent remittance processing mechanism, efficient automation and precise adaptation are achieved throughout the entire cross-border settlement process. The system first automatically matches the optimal parsing rules based on incoming message characteristics (such as channel type and message format version), accurately mapping source message fields to business fields and eliminating format adaptation errors caused by manual parsing. During the remittance process, the system dynamically determines target message characteristics based on remittance information (remittance path, clearing requirements, etc.) and invokes corresponding reverse parsing rules to convert business data into remittance messages. This supports intelligent generation of messages for multiple clearing channels, such as SWIFT and CIPS, and avoids remittance failures due to format incompatibilities. Through a feature-driven, two-way parsing architecture, this approach achieves the flexible processing capability of "one-time access, multi-channel adaptation," enabling financial institutions to quickly respond to rule changes across different clearing channels, significantly reducing the operating costs and compliance risks of cross-border settlement services. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0011] Figure 1 10 is a flow chart of steps S101-S103 provided in an embodiment of the present application; Figure 2 This is a schematic diagram of the cross-border settlement message processing principle provided by an embodiment of the present application; Figure 3 This is a schematic diagram of the structure of a cross-border settlement message processing device provided in an embodiment of the present application; Figure 4 It is a schematic diagram of the composition structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0012] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of illustration and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowcharts can be implemented out of sequence, and steps without logical context can be reversed or implemented simultaneously. In addition, those skilled in the art, under the guidance of the contents of this application, can add one or more other operations to the flowchart, or remove one or more operations from the flowchart.

[0013] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present application.

[0015] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0016] It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the existence of the features declared thereafter, but does not exclude the addition of other features.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs. The terms used herein are for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0018] See also Figure 1 , Figure 1 This is a flow chart of steps S101-S103 of the cross-border settlement message processing method provided in the embodiment of the present application, which will be combined with Figure 1 Steps S101-S103 are shown for explanation.

[0019] In step S101, in response to an incoming message initiation request, a first message is received, and a first message feature corresponding to the target message is determined.

[0020] In step S102, a first parsing rule that matches the first message feature is called from preset parsing rules, and based on the first parsing rule, the message field of the first message is mapped to the first service field to obtain a second message.

[0021] In step S103, whether remittance is required is determined based on the business characteristics. If remittance is required, the second message characteristics are determined based on the remittance information, and a second parsing rule matching the second message characteristics is called from the preset parsing rules. Based on the second parsing rule, the second business field is mapped to the message field of the second message to obtain a third message; wherein, the third message is a remittance message.

[0022] See Figure 2 , Figure 2 This is a schematic diagram of the cross-border settlement message processing principle provided by the embodiment of the present application, such as Figure 2 As shown, the embodiment of the present application is designed to efficiently and accurately process various messages in cross-border settlement scenarios. Through automated rule matching and field mapping, it can achieve rapid conversion and processing of messages in different business links (such as remittance and remittance), improve cross-border settlement efficiency and reduce manual operation risks. Specifically: The system responds to externally initiated message requests (such as SWIFT messages, CIPS messages, etc.), receives the original message (first message), extracts key features (such as message type, format, sender identification, business scenario, etc.) and determines the first message features (such as "channel features", "type features", etc.) based on the features.

[0023] Afterwards, the first parsing rule (such as the MT103 message parsing rule) that matches the first message feature is called from the preset parsing rule library, and the original field of the first message (such as "59: Beneficiary Account") is mapped to the first business field within the system (such as "Payee Account Number") to generate the second message (structured business data) for subsequent business processing.

[0024] Based on the business characteristics of the second message (such as amount, currency, and beneficiary information), a determination is made as to whether remittance transfer is required (e.g., in scenarios involving intermediary bank collection or multi-level clearing). If remittance transfer is required, the remittance transfer information (such as the intermediary bank account number, remittance routing, and fee bearer) is extracted, and the second message characteristics (e.g., "remittance to agent bank message") are determined. The matching second parsing rule is then invoked, and the second business field (e.g., "Original beneficiary information") is reverse-mapped to the fields of the remittance transfer message (e.g., adding remittance instructions in "72: Postscript"). This generates a third message (the remittance transfer message) and sends it to downstream systems or external institutions.

[0025] In some embodiments, the method further comprises: If remittance is not required, the second message is used as an inward remittance message and the inward remittance payment service is completed.

[0026] Here, if remittance is not required, the second message is directly used as the inward remittance message to trigger the inward remittance release process (such as updating the account balance, generating a receipt, etc.).

[0027] The above approach, through a preset parsing rule base, enables rapid identification of message features and field mapping, reduces manual intervention, supports multiple message formats (such as SWIFT, ISO 20022, CIPS, etc.), and improves system compatibility. The remittance judgment logic can be dynamically configured based on business rules (such as amount thresholds, currency restrictions, and whitelists of partner institutions). It also supports custom parsing rules to adapt to regulatory requirements in different regions or institutional business characteristics.

[0028] In a typical application scenario, an inbound remittance message is received from abroad, and a determination is made as to whether it needs to be remitted to a domestic beneficiary through an intermediary bank. In the correspondent bank model, the original message is converted into a remittance message that meets the correspondent bank's requirements. Specific remarks or identification (such as anti-money laundering information) are then added to the remittance message in accordance with regulatory requirements.

[0029] As an example, a SWIFT MT103 message (the first message) is received and identified as "cross-border personal remittance." The MT103 parsing rules are then applied to map the fields to internal business data (the second message). The recipient is then determined to be a non-pass-through bank and requires remittance to a correspondent bank. The correspondent bank information is extracted, and a remittance postscript (e.g., " / BEN / / OUR / Correspondent Bank Account Number: XXX") is generated. The remittance parsing rules are then applied to generate an MT202 message (the third message) and send it to the correspondent bank. If remittance is not required, the beneficiary's account is credited directly and a receipt is generated.

[0030] The embodiments of the present application can be flexibly extended to other financial business scenarios (such as trade financing, securities settlement, etc.), providing efficient and secure message processing support for cross-border financial business.

[0031] In some embodiments, the remittance information specifies multiple clearing channels, and the second message characteristic is the best clearing channel among the multiple clearing channels, and the best clearing channel is determined by: The optimal clearing channel is dynamically selected based on the remittance instructing bank code, receiving bank code, currency, amount, preset channel priority matrix and real-time status interface in the remittance information; wherein, the channel priority matrix is ​​configured through a visual interface and stored in a first data table, and the configuration parameters include the channel order corresponding to the currency, the amount threshold and the interest value date time window.

[0032] Here, when the remittance information contains multiple optional clearing channels, the system dynamically selects the optimal path through the following steps: 1. Input parameters: The system extracts the following key data from the remittance information as the basis for decision-making: Remittance Instruction Bank Code (such as SWIFT BIC): identifies the bank that originates the remittance or the intermediary bank.

[0033] Beneficiary bank code: identifies the bank of the final beneficiary.

[0034] Currency (e.g. USD / CNY / EUR): Different currencies may support different clearing channels (e.g. RMB prioritizes CIPS).

[0035] Amount: Larger payments may require higher-cost but more stable channels (such as SWIFT GPI).

[0036] Preset channel priority matrix: static rules stored in the first data table (configured through the visual interface).

[0037] Real-time status interface: Dynamically obtain the current status of each channel (such as availability, cost, timeliness, limit, etc.).

[0038] The channel priority matrix (first data table) is used to define the default channel order and additional rules for different currencies and amount ranges. As an example, see Table 1, which is a portion of the first data table provided in this embodiment of the application.

[0039] Table 1

[0040] Channel order: Arrange by priority from high to low (e.g. USD prioritizes SWIFT GPI).

[0041] Amount threshold: When the amount exceeds this threshold, the use of a higher priority channel is forced (for example, for large amounts, a low-cost but slow correspondent bank is disabled).

[0042] Value Date Window: Some channels are only available during certain time periods (e.g. closed on non-business days).

[0043] Special rules: Exceptions that override the default logic (such as disabling certain channels for specific customer types).

[0044] The system filters and sorts clearing channels according to the following steps: Based on the remitting / receiving bank code and currency, exclude channels that don't support the service (e.g., USD remittances cannot be processed through CIPS, which only supports CNY). Adjust the default channel order based on the amount threshold and value date window (e.g., small USD amounts can be processed through correspondent banks on weekdays, but must be processed through SWIFT on weekdays). Check the current status of remaining channels (e.g., whether SWIFT GPI is congested, whether correspondent bank fees have increased). Assign a weighted score to each channel based on factors such as cost, timeliness, and compliance, and select the channel with the highest overall score.

[0045] For example, if SWIFT GPI has high fees but meets the timeliness requirement, while the correspondent bank fee is low but requires manual intervention, the automatic selection will be based on business needs (such as customer requirements for timeliness).

[0046] The optimal clearing channel ultimately determined will serve as the second message feature for subsequent steps, calling the corresponding parsing rules (e.g., SWIFT messages use the MT202 template, CIPS uses the 111 template), and appending channel-specific information to the remittance message (e.g., the "72: Postscript" field of the SWIFT message indicates "via SWIFT GPI").

[0047] The above approach, through the combination of static rules (priority matrix) and dynamic data (real-time status), enables intelligent selection of clearing channels. The core goal is to achieve the most efficient cross-border payment at the lowest cost while maintaining compliance.

[0048] In some embodiments, if the optimal clearing channel is unavailable, it will automatically switch to the suboptimal channel according to a preset fallback order, and record the channel switching log; wherein, the fallback order is dynamically adjusted based on the region where the receiving bank is located, fee priority, and historical success rate.

[0049] Here, the system detects that the optimal clearing channel is unavailable (for example, the SWIFT GPI interface times out or returns an error code (such as "channel congestion"), CIPS cannot process due to the closure of the RMB clearing window, or the correspondent bank responds with "insufficient account balance" and is unable to forward the message). The system reads the list of suboptimal channels from the preset fallback strategy library, and the order is dynamically generated based on the following dimensions: Region where the beneficiary bank is located: Prioritize clearing channels located in the same region as the beneficiary bank (to reduce transit links and lower the failure rate).

[0050] Example: If the beneficiary bank is located in Europe, the priority is to fall back to TARGET2 (Eurozone Direct) rather than SWIFT.

[0051] Cost priority: Choose channels with lower costs while meeting time requirements.

[0052] For example, if the best channel is SWIFT GPI (high fees), the next best option might be a local correspondent bank (low fees but slightly slower timeliness).

[0053] Historical success rate: Prioritizes the channel with the highest transaction success rate for the receiving bank or the same region in the past 24 hours.

[0054] Example: If correspondent bank A has a historical success rate of 98% for a Southeast Asian bank, while correspondent bank B has a success rate of only 85%, then correspondent bank A is preferred.

[0055] Dynamic adjustment logic: The fallback order is not fixed and can be dynamically sorted based on real-time data. For example: Peak hours: If SWIFT GPI is congested, the system may place the "local correspondent bank" higher in the queue (even if its fees are slightly higher).

[0056] Regulatory changes: If a channel is suddenly banned (e.g. a country imposes sanctions on SWIFT), the system will automatically remove the channel and re-order it.

[0057] The system tries the suboptimal channels in the fallback order until an available channel is found. Then, it generates a corresponding retransmission message for the selected suboptimal channel (such as switching from MT202 to CIPS 111 message) and adds a switching mark (such as " / REMARK / FALLBACK TO AGENT BANK DUE TO SWIFT UNAVAILABLE") to the message for downstream systems to identify.

[0058] In some embodiments, the preset parsing rules include multiple rules, each rule represents a mapping relationship between a source message field of a format and a business field; the mapping rules are stored in a second data table, and when processing the message, the corresponding mapping rules are dynamically called through the first message feature or the second message feature, and the first message feature or the second message feature includes: channel feature and type feature.

[0059] The embodiment of the present application presets multiple sets of parsing rules, each set of rules corresponds to a source message format, and defines the mapping relationship between its fields and business columns. For example: SWIFT MT202 Rules: :20:CNY123456789→Business column "Transaction Number" :32A:240315USD100,000.00 → Transaction field: "Value Date = 2024-03-15, Currency = USD, Amount = 100,000.00" CIPS 111 message rules: <ccyamt> 100000.00< / ccyamt> →Business column "Amount" <valdt> 2024-03-15< / valdt> →Business column "Value Date" ISO 20022 pacs.008 rules: <orgnltxref><IntrBkSttlmAmtCcy="USD"> 100000< / orgnltxref> →Business column "Original transaction amount" All mapping rules are stored in the second data table, please refer to Table 2, which is part of the data in the second data table provided in the embodiment of the present application.

[0060] Table 2

[0061] When processing a message, the system locates the matching parsing rule based on the first or second message feature. Features include two types: Channel characteristics: Identifies the clearing channel used by the message (such as SWIFT, CIPS, correspondent bank).

[0062] Type feature: identifies the format type of the message (such as MT202, 111, pacs.008).

[0063] As an example: Message A: Channel feature = SWIFT, Type feature = MT202 → Invoke the SWIFT MT202 rule set.

[0064] Message B: Channel feature = CIPS, Type feature = 111 → Invoke the CIPS 111 rule set.

[0065] The system selects parsing rules as follows: Parse channel characteristics (such as the first three digits of the SWIFT BIC) and type characteristics (such as the message type code) from the message header or metadata. Filter the rules in the second data table to find the following: SELECT * FROM MAPPING_RULES WHERE message format = [type feature] AND (channel feature = [channel feature] OR channel feature = 'ALL'); If multiple rules match, they are sorted by rule ID priority or condition expression strictness (for example, rules that exactly match field paths take precedence over fuzzy matches). For each source field, the matched rule is applied to generate the target business field value, and the mapping process is recorded (for debugging or auditing).

[0066] In some embodiments, the preset parsing rules are updated in the following manner: Performing addition, deletion, modification, and query processing on the preset parsing rules stored in the second data table through a human-computer interaction interface; if the preset parsing rules are changed, generating a new version number and retaining the old version of the rules; Alternatively, batch import / export rule packages; wherein the rule packages include channel codes, message types, source fields, target fields, and conversion logic.

[0067] The system provides a visual interface, allowing administrators to directly add, delete, modify, and query parsing rules in the second data table. For example, when adding a new message format, the interface allows configuration of the mapping between source fields and business columns, conversion logic, and default values. Each time a rule is changed, the system automatically generates a new version number (e.g., V1.0 → V1.1) and retains historical versions for rollback or audit purposes. This model supports real-time debugging and is suitable for frequent, small-scale adjustments. However, it requires manual, item-by-item adjustments, limiting efficiency due to operational complexity.

[0068] To improve the efficiency of large-scale rule updates, the system supports batch operations in the form of rule packages. Rule packages are structured files (such as JSON / XML) that contain metadata such as channel codes, message types, source fields, target fields, and conversion logic. For example, when importing a rule package covering five channels and 20 message types, the system automatically parses the file and writes it in batches to a secondary data table, while also verifying the validity of field paths. The export function can be used for backup or cross-environment synchronization of rules to ensure consistent configuration between test and production environments.

[0069] The human-computer interface and rule package import / export complement each other. The former is suitable for fine-grained adjustments (such as fixing a parsing error in a single field), while the latter excels at large-scale deployment (such as initializing rules when launching a new channel). The version control mechanism ensures the traceability of rule changes, preventing parsing anomalies caused by incorrect operations. For example, when a bank upgrades its message format, administrators can first test the new rules through the interface. After confirming that they are correct, they can export the rule package and apply it to all relevant systems in batches, significantly reducing maintenance costs and risks.

[0070] In some embodiments, the method further comprises: Perform data integrity checks on the mapping results, including but not limited to: mandatory field missing detection, field length compliance check, and key business code validity verification; Furthermore, before making a transfer decision, we screen transfer information for anti-money laundering compliance, automatically blocking transactions involving high-risk regions or blacklisted entities by invoking a third-party sanctions list database and an internal risk rule engine; After generating the third message, perform a value date timing check to ensure that the value date of the forwarded message is not earlier than the current system date and meets the deadline requirements of the target clearing channel; If any verification fails, an exception work order will be automatically generated and pushed to the preset operation monitoring platform, while recording the reason for the verification failure and context message data.

[0071] Here, after the system completes the mapping of the source message to the business field, it immediately starts the data integrity check, covering the detection of missing mandatory fields (such as interception when the core fields such as transaction number and amount are empty), field length compliance check (such as SWIFT MT202: The :20: field length must be ≤16 characters) and key business code validity verification (such as whether the currency code complies with the ISO 4217 standard). Through the pre-set verification rule library (decoupled from the parsing rules), the system can flexibly adapt to the compliance requirements of different channels, such as mandatory verification of CIPS messages. <valdt>Check whether the field is a valid working day to avoid subsequent process interruptions due to data errors.

[0072] Before determining whether a remittance is being processed, this embodiment automatically triggers an anti-money laundering (AML) screening mechanism. This mechanism uses third-party sanctions databases (e.g., WorldCheck, OFAC) to compare counterparty information (e.g., beneficiary bank BIC, beneficiary account number) in real time. Furthermore, it uses an internal risk rules engine to assess transaction characteristics (e.g., frequent large-value transfers, high-risk routing). If any risk rule is triggered (e.g., a transaction involving an Iranian entity or an amount exceeding a single transaction threshold), the system immediately intercepts the transaction and generates a risk event. The screening evidence (e.g., the matching sanctions list entry ID) is also recorded for review by the compliance team, achieving a seamless transition from data analysis to risk control.

[0073] After generating the third message (the forwarding message), the system performs a time sequence check on the value date. First, it verifies whether the value date is ≥ the current system date (to prevent future date errors). Secondly, it compares the value date to the target clearing channel's deadline (for example, if the CIPS daytime session deadline is 16:30, if the value date falls on the same day but the submission time has passed, the deadline will be automatically postponed to the next business day). If any of these checks fails, the system automatically generates an exception ticket (containing a unique error code, failure node, and context message fragment), pushes it to the operations monitoring platform, and triggers an alert notification (e.g., email / SMS). Operations personnel can quickly identify the issue through the ticket system, correct it, and re-trigger the process, forming a closed-loop management mechanism of "verify-intercept-repair-retry," significantly improving processing efficiency and data quality.

[0074] In summary, the embodiments of the present application have the following beneficial effects: Through dynamic feature matching and intelligent routing technology, adaptive parsing of multi-format messages such as SWIFT and CIPS and real-time selection of the best clearing channel are achieved, improving message processing efficiency and channel selection success rate; at the same time, anti-money laundering screening, data integrity verification and interest value date timing control are embedded in the processing flow, combined with the automatic generation of abnormal work orders and the full life cycle management of rule versions, significantly improving the compliance, timeliness and maintainability of cross-border settlement business.

[0075] Based on the same inventive concept, an embodiment of the present application also provides a cross-border settlement message processing device corresponding to the cross-border settlement message processing method in the first embodiment. Since the principle of solving the problem by the device in the embodiment of the present application is similar to the above-mentioned cross-border settlement message processing method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be repeated.

[0076] like Figure 3 As shown, Figure 3 : is a schematic diagram of the structure of the cross-border settlement message processing device 300 provided in an embodiment of the present application. The cross-border settlement message processing device 300 includes: The determination module 301 is configured to receive a first message in response to an incoming message initiation request and determine a first message feature corresponding to the target message; A first mapping module 302 is configured to call a first parsing rule that matches the first message feature from a preset parsing rule, and map the message field of the first message to a first service field based on the first parsing rule to obtain a second message; The second mapping module 303 is used to determine whether remittance is required based on the business characteristics. If remittance is required, the second message characteristics are determined according to the remittance information, a second parsing rule that matches the second message characteristics is called from the preset parsing rules, and the second business field is mapped to the message field of the second message based on the second parsing rule to obtain a third message; wherein the third message is a remittance message.

[0077] It should be understood by those skilled in the art that Figure 3 The implementation functions of each unit in the cross-border settlement message processing device 300 shown can be understood by referring to the relevant description of the aforementioned cross-border settlement message processing method. Figure 3 The functions of each unit in the cross-border settlement message processing device 300 shown can be implemented by a program running on a processor, or by a specific logic circuit.

[0078] In a possible implementation, the remittance information specifies multiple clearing channels, and the second message characteristic is the best clearing channel among the multiple clearing channels. The best clearing channel is determined by: The optimal clearing channel is dynamically selected based on the remittance instructing bank code, receiving bank code, currency, amount, preset channel priority matrix and real-time status interface in the remittance information; wherein, the channel priority matrix is ​​configured through a visual interface and stored in a first data table, and the configuration parameters include the channel order corresponding to the currency, the amount threshold and the interest value date time window.

[0079] In one possible implementation, if the optimal clearing channel is unavailable, it will automatically switch to the suboptimal channel according to a preset fallback order, and record the channel switching log; wherein, the fallback order is dynamically adjusted based on the region where the receiving bank is located, fee priority, and historical success rate.

[0080] In one possible implementation, the preset parsing rules include multiple rules, each rule representing a mapping relationship between a source message field of a format and a business field; the mapping rules are stored in a second data table, and when processing a message, the corresponding mapping rules are dynamically called through the first message feature or the second message feature, and the first message feature or the second message feature includes: channel feature and type feature.

[0081] In a possible implementation, the preset parsing rules are updated in the following manner: Performing addition, deletion, modification, and query processing on the preset parsing rules stored in the second data table through a human-computer interaction interface; if the preset parsing rules are changed, generating a new version number and retaining the old version of the rules; Alternatively, batch import / export rule packages; wherein the rule packages include channel codes, message types, source fields, target fields, and conversion logic.

[0082] In one possible implementation, the method further includes: Perform data integrity checks on the mapping results, including but not limited to: mandatory field missing detection, field length compliance check, and key business code validity verification; Furthermore, before making a transfer decision, we screen transfer information for anti-money laundering compliance, automatically blocking transactions involving high-risk regions or blacklisted entities by invoking a third-party sanctions list database and an internal risk rule engine; After generating the third message, perform a value date timing check to ensure that the value date of the forwarded message is not earlier than the current system date and meets the deadline requirements of the target clearing channel; If any verification fails, an exception work order will be automatically generated and pushed to the preset operation monitoring platform, while recording the reason for the verification failure and context message data.

[0083] In one possible implementation, the method further includes: If remittance is not required, the second message is used as an inward remittance message and the inward remittance payment service is completed.

[0084] The above-mentioned cross-border settlement message processing device realizes the adaptive parsing of multi-format messages such as SWIFT and CIPS and the real-time selection of the best clearing channel through dynamic feature matching and intelligent routing technology, thereby improving the message processing efficiency and the success rate of channel selection; at the same time, it embeds anti-money laundering screening, data integrity verification and interest value date timing control into the processing flow, combines the automatic generation of abnormal work orders and the full life cycle management of rule versions, and significantly improves the compliance, timeliness and maintainability of cross-border settlement business.

[0085] like Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of an electronic device 400 provided in an embodiment of the present application. The electronic device 400 includes: A processor 401, a storage medium 402 and a bus 403, wherein the storage medium 402 stores machine-readable instructions executable by the processor 401. When the electronic device 400 is running, the processor 401 communicates with the storage medium 402 through the bus 403, and the processor 401 executes the machine-readable instructions to perform the steps of the cross-border settlement message processing method described in the embodiment of the present application.

[0086] In actual application, the various components in the electronic device 400 are coupled together via the bus 403. It is understood that the bus 403 is used to realize the connection and communication between these components. In addition to the data bus, the bus 403 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, Figure 4 Various buses are labeled as bus 403.

[0087] Through dynamic feature matching and intelligent routing technology, the above-mentioned electronic equipment realizes the adaptive parsing of multi-format messages such as SWIFT and CIPS and the real-time selection of the best clearing channel, thereby improving the message processing efficiency and the success rate of channel selection; at the same time, it embeds anti-money laundering screening, data integrity verification and interest value date timing control into the processing flow, combines the automatic generation of abnormal work orders and the full life cycle management of rule versions, and significantly improves the compliance, timeliness and maintainability of cross-border settlement business.

[0088] An embodiment of the present application also provides a computer-readable storage medium, which stores executable instructions. When the executable instructions are executed by at least one processor 401, the cross-border settlement message processing method described in the embodiment of the present application is implemented.

[0089] In some embodiments, the storage medium can be a magnetic random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface storage, an optical disc, or a compact disc read-only memory (CD-ROM); it can also be various devices including one or any combination of the above memories.

[0090] In some embodiments, executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0091] As an example, executable instructions may, but do not necessarily, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (for example, files storing one or more modules, subroutines, or code portions).

[0092] By way of example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0093] The above-mentioned computer-readable storage medium realizes adaptive parsing of multi-format messages such as SWIFT and CIPS and real-time selection of the best clearing channel through dynamic feature matching and intelligent routing technology, thereby improving message processing efficiency and channel selection success rate; at the same time, it embeds anti-money laundering screening, data integrity verification and interest value date timing control into the processing flow, combines the automatic generation of abnormal work orders and the full life cycle management of rule versions, and significantly improves the compliance, timeliness and maintainability of cross-border settlement business.

[0094] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0095] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical units, that is, they may be located in one place or distributed across multiple network elements. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0096] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0097] If the functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, or the portion that contributes to the prior art, or the portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, platform server, or network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application. The aforementioned storage media include various media that can store program code, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.

[0098] The above are only specific embodiments of the present application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.< / valdt>

Claims

1. A cross-border settlement message processing method, characterized in that: The method comprises: In response to the incoming message initiation request, receiving a first message and determining a first message feature corresponding to a target message; Invoking a first parsing rule that matches the first message feature from preset parsing rules, and mapping a message field of the first message to a first service field based on the first parsing rule to obtain a second message; Determine whether remittance is required based on the business characteristics. If remittance is required, determine the second message characteristics based on the remittance information, call a second parsing rule that matches the second message characteristics from the preset parsing rules, and map the second business field to the message field of the second message based on the second parsing rule to obtain a third message; wherein the third message is a remittance message.

2. The method according to claim 1, characterized in that The remittance information specifies multiple clearing channels, and the second message characteristic is the best clearing channel among the multiple clearing channels. The best clearing channel is determined by: The optimal clearing channel is dynamically selected based on the remittance instructing bank code, receiving bank code, currency, amount, preset channel priority matrix and real-time status interface in the remittance information; wherein, the channel priority matrix is ​​configured through a visual interface and stored in a first data table, and the configuration parameters include the channel order corresponding to the currency, the amount threshold and the interest value date time window.

3. The method according to claim 2, characterized in that If the optimal clearing channel is unavailable, it will automatically switch to the suboptimal channel according to the preset fallback order, and record the channel switching log; wherein, the fallback order is dynamically adjusted based on the region where the receiving bank is located, fee priority, and historical success rate.

4. The method according to claim 1, wherein The preset parsing rules include multiple rules, each rule represents a mapping relationship between a source message field of a format and a business field; the mapping rules are stored in a second data table, and when processing a message, the corresponding mapping rules are dynamically called through the first message feature or the second message feature, and the first message feature or the second message feature includes: channel feature and type feature.

5. The method according to claim 4, characterized in that The preset parsing rules are updated in the following way: Performing addition, deletion, modification, and query processing on the preset parsing rules stored in the second data table through a human-computer interaction interface; if the preset parsing rules are changed, generating a new version number and retaining the old version of the rules; Alternatively, batch import / export rule packages; wherein the rule packages include channel codes, message types, source fields, target fields, and conversion logic.

6. The method according to claim 1, characterized in that The method further comprises: Perform data integrity checks on the mapping results, including but not limited to: mandatory field missing detection, field length compliance check, and key business code validity verification; Furthermore, before making a transfer decision, the transfer information is screened for anti-money laundering compliance, and transactions involving high-risk countries / regions or blacklisted entities are automatically blocked by invoking a third-party sanctions list database and an internal risk rule engine; After generating the third message, perform a value date timing check to ensure that the value date of the forwarded message is not earlier than the current system date and meets the deadline requirements of the target clearing channel; If any verification fails, an exception work order will be automatically generated and pushed to the preset operation monitoring platform, while recording the reason for the verification failure and context message data.

7. The method according to claim 1, characterized in that The method further comprises: If remittance is not required, the second message is used as an inward remittance message and the inward remittance payment service is completed.

8. A cross-border settlement message processing device, characterized in that: The device comprises: a determination module, configured to receive a first message in response to an incoming message initiation request, and determine a first message feature corresponding to a target message; a first mapping module, configured to call a first parsing rule that matches the first message feature from preset parsing rules, and map a message field of the first message to a first service field based on the first parsing rule to obtain a second message; The second mapping module is used to determine whether remittance is required based on the business characteristics. If remittance is required, the second message characteristics are determined according to the remittance information, a second parsing rule that matches the second message characteristics is called from the preset parsing rules, and the second business field is mapped to the message field of the second message based on the second parsing rule to obtain a third message; wherein the third message is a remittance message.

9. An electronic device, characterized in that: include: A processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the storage medium communicate through the bus, and the processor executes the machine-readable instructions to execute the cross-border settlement message processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the cross-border settlement message processing method according to any one of claims 1 to 7 is executed.

Images