Version upgrading method of cross-border payment system, electronic equipment and computer readable medium

Abstract

The invention discloses a version upgrading method of a cross-border payment system. The version upgrading method comprises the following steps: obtaining a channel increase demand; disassembling the channel increase demand to obtain a plurality of demand keywords; indexing in the business relation graph by using the plurality of demand keywords; generating a conflict report under the condition that a service node pair conflicting with the channel increase demand exists in the service relation graph; under the condition that no business node pair conflicting with the channel increase demand exists in the business relation graph, a target payment channel is filtered out according to the multiple keywords, and the target payment channel is a payment channel meeting the channel increase demand; verifying the target payment channel by using a rule verification engine; and adding an interface corresponding to the target payment channel under the condition that the target payment channel meets the compliance verification rule. The invention further provides electronic equipment and a computer readable medium.

Description

Technical Field

[0001] This invention relates to the field of cross-border payments, and more specifically, to a method for upgrading a cross-border payment system, an electronic device, and a computer-readable medium. Background Technology

[0002] For cross-border payment platforms, a diverse range of payment channels is crucial for ensuring smooth transactions. Furthermore, the unique nature of cross-border payments lies in the frequent changes in compliance policies. Consequently, it is necessary to eliminate some non-compliant payment channels and increase the number of compliant ones in accordance with these policies.

[0003] When additional payment channels are needed, the corresponding version of the cross-border payment platform needs to be upgraded. Therefore, how to upgrade the version of the cross-border payment platform when adding payment channels is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0004] This invention aims to address, to a certain extent, one of the technical problems in related technologies. To this end, this invention provides a method for upgrading a cross-border payment system, an electronic device, and a computer-readable medium.

[0005] To achieve the above objectives, as a first aspect of the present invention, a method for upgrading a cross-border payment system is disclosed, wherein the method includes: Increased demand due to expanded acquisition channels; The increased demand from the aforementioned channels was broken down into multiple demand keywords; Index the business relationship graph using multiple demand keywords; If a conflict report is generated in the business relationship graph where there is a pair of business nodes that conflict with the increased demand from the channel; If there are no business node pairs in the business relationship graph that conflict with the channel expansion requirement, target payment channels are filtered out based on multiple keywords, wherein the target payment channels are payment channels that meet the channel expansion requirement; The target payment channel is verified using a rule verification engine; If the target payment channel meets the compliance verification rules, add an interface corresponding to the target payment channel.

[0006] Optionally, the step of using a rule verification engine to verify the target payment channel includes: If the target payment channel meets the timeliness requirements in the channel addition needs, it is matched with the State Administration of Foreign Exchange whitelist according to the bank interface standard of the target payment channel; If the target payment channel's bank interface standard exists in the State Administration of Foreign Exchange's whitelist, the target payment channel is determined to meet the compliance verification rules.

[0007] Optionally, the indexing of the business relationship graph using multiple demand keywords includes: Traverse each business node in the business relationship graph and the edges between each business node; Filter out target business node pairs, wherein the target business node pair is a business node pair that simultaneously includes attributes associated with the keyword with the highest priority; If there is a conflict between the target business nodes, it is determined that there is a conflict between the business relationship graph and the channel's increased demand.

[0008] Optionally, the keywords include time-sensitive keywords and regulatory rule keywords, with the time-sensitive keywords having a higher priority than the regulatory rule keywords. The target service nodes are subject to conflict in the following situations: The timeliness of the two service nodes in the target service node pair is inconsistent; and The regulatory rules keywords for the two business nodes in the target business node pair are inconsistent.

[0009] Optionally, the conflict report carries the following information: Conflict identification information, information on conflicting business node pairs, and conflict type information.

[0010] Optionally, if there are no business node pairs in the business relationship graph that conflict with the channel addition requirement, after filtering out the target payment channel based on multiple keywords, the version upgrade method further includes: Match multiple of the aforementioned requirement keywords with the defined requirement template; If there are missing fields in multiple of the aforementioned keyword requirements, a field completion notification will be generated. Upon receiving the completion information, a data structure matching the set requirement template is generated using multiple requirement keywords and the completion information. Write the data structure into the requirements library.

[0011] Optionally, the acquisition channels increase the demand, including: Interact with various requirement systems to obtain new requirements from each system; The field information of the newly added requirements is identified, and the channels that added the requirements are selected.

[0012] Optionally, the new requirement carries at least one of the following fields: Demand identification information, source system information, and business entity information.

[0013] As a second aspect of the present invention, an electronic device is provided, the electronic device comprising: One or more processors; A storage module storing an executable program, which enables the version upgrade method to be implemented when the one or more processors invoke the executable program.

[0014] As a third aspect of the invention, a computer-readable medium is provided, wherein one or more computer programs are stored thereon, which, when invoked, enable the version upgrade method.

[0015] Channel addition requests are typically provided by the business department, describing multiple requirements the business party has for payment channels. The business relationship graph is a knowledge graph built based on business nodes (i.e., existing requirements) in the requirement database. In this embodiment, the requirement is broken down into multiple keywords and indexed in the business relationship graph to confirm whether the current requirement conflicts with existing requirements in the requirement database. Only when the current channel addition request does not conflict with existing requirements is the target payment channel further selected and its compliance verified. Only when the target payment channel is compliant is the current payment system upgraded to add the interface corresponding to the target payment channel to the payment system. In other words, the version upgrade method provided in this embodiment ensures that the added payment channel is compliant.

[0016] These features and advantages of the present invention will be disclosed in detail in the following specific embodiments and accompanying drawings. The preferred embodiments or means of the present invention will be shown in detail in conjunction with the accompanying drawings, but are not intended to limit the technical solutions of the present invention. In addition, each of these features, elements and components appearing in the following text and drawings is a plurality of, and different symbols or numbers are used for convenience of representation, but all represent parts with the same or similar construction or function. Attached Figure Description

[0017] The present invention will be further described below with reference to the accompanying drawings: Figure 1 This is a flowchart of the version upgrade method provided in the embodiments of this application; Figure 2 This is a flowchart of an optional implementation of step S160; Figure 3 This is a flowchart of an optional implementation of step S130; Figure 4 This is a flowchart of an optional implementation of step S110; Figure 5 This is a schematic diagram of the electronic device provided in the second aspect of the present invention; Figure 6 This is a schematic diagram of a computer-readable medium.

[0018] Explanation of reference numerals in the attached figures 101: Processor; 102: Memory 103: I / O Interface 104: Bus Detailed Implementation Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described are intended to explain the present invention and should not be construed as limiting the invention.

[0019] The terms "an embodiment," "example," or "example" used in this specification refer to a particular feature, structure, or characteristic described in connection with the embodiment itself that may be included in at least one embodiment disclosed in this application. The phrase "in an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0020] As a first aspect of the present invention, a method for upgrading a cross-border payment system is provided, wherein, as Figure 1 As shown, the version upgrade method includes: In step S110, the demand for acquiring channels is increased; In step S120, the channel demand is broken down to obtain multiple demand keywords; In step S130, multiple demand keywords are used to index the business relationship graph; In step S140, if there is a pair of business nodes in the business relationship graph that conflict with the channel's increased demand, a conflict report is generated. In step S150, if there are no business node pairs in the business relationship graph that conflict with the channel increase requirement, a target payment channel is filtered out based on multiple keywords, wherein the target payment channel is a payment channel that meets the channel increase requirement; In step S160, the target payment channel is verified using a rule verification engine; In step S170, if the target payment channel meets the compliance verification rules, an interface corresponding to the target payment channel is added.

[0021] Channel addition requests are typically provided by the business department, describing multiple requirements the business party has for payment channels. The business relationship graph is a knowledge graph built based on business nodes (i.e., existing requirements) in the requirement database. In this embodiment, the requirement is broken down into multiple keywords and indexed in the business relationship graph to confirm whether the current requirement conflicts with existing requirements in the requirement database. Only when the current channel addition request does not conflict with existing requirements is the target payment channel further selected and its compliance verified. Only when the target payment channel is compliant is the current payment system upgraded to add the interface corresponding to the target payment channel to the payment system. In other words, the version upgrade method provided in this embodiment ensures that the added payment channel is compliant.

[0022] It should also be noted that compared with regular domestic payments, the review and verification process for the special scenario of "cross-border payments" is more complex. Correspondingly, the requirements for cross-border payment channels are also more stringent. Therefore, in order to facilitate subsequent inquiries by business parties, a knowledge graph needs to be constructed.

[0023] In this embodiment, no special limitation is made on how to use the rule verification engine to verify the target payment channel. As an optional implementation method, such as... Figure 2 As shown, step S160 includes: In step S161, if the target payment channel meets the timeliness requirements in the channel addition demand, the target payment channel is matched with the State Administration of Foreign Exchange whitelist according to the bank interface standard of the target payment channel; In step S162, if the target payment channel's bank interface standard exists in the State Administration of Foreign Exchange's whitelist, the target payment channel is determined to meet the compliance verification rules.

[0024] Timeliness is a crucial indicator for improving user experience, and it is especially important for cross-border payments. Specifically, exchange rates fluctuate over time, and failure to receive or pay payments promptly may result in financial losses for users due to exchange rate changes. In this embodiment, timeliness is prioritized during compliance verification. Once the timeliness of the target payment channel meets the requirements, further verification is performed to determine whether the bank corresponding to the target payment channel is on the designated whitelist set by the State Administration of Foreign Exchange.

[0025] In this embodiment of the application, the pseudocode for implementing steps S171 and S172 is as follows: def check_compliance(demand):if demand.business_speed == "T+0":if "SAFE Whitelist" not in demand.regulatory_entities:send_alert(creator_id, "Missing SAFE Whitelist association! Additional terms required") Specifically, the first step is to verify whether the timeliness of the target payment channel meets the "T+0" requirement, that is, whether the payment can be completed on the same day as the transaction.

[0026] If the timeliness requirement is "T+0", then it is necessary to determine whether the bank corresponding to the channel is on the State Administration of Foreign Exchange's whitelist. If it is not on the State Administration of Foreign Exchange's whitelist, then an alarm is generated.

[0027] In this embodiment, no special limitation is made on how step S130 is specifically performed. As an optional implementation, such as... Figure 3 As shown, the indexing of the business relationship graph using multiple demand keywords includes: In step S131, the business nodes in the business relationship graph and the edges between the business nodes are traversed. In step S132, target business node pairs are selected, wherein the target business node pairs are business node pairs that simultaneously include attributes associated with the keyword with the highest priority. In step S133, if there is a conflict between the target business nodes, it is determined that there is a conflict between the business relationship graph and the channel increase requirement.

[0028] A business relationship graph can be viewed as a dependency chain between various business nodes in a payment system. For example, a payment node might be associated with an approval node. If the timeliness requirement for a payment node is T+0, while the timeliness requirement for the approval node associated with that payment node is T+1, then there is a conflict between the two.

[0029] In this embodiment, by traversing the business relationship graph, it can be determined whether there are any associated nodes that conflict with the selected payment node. If a conflict exists, no further compliance verification is required.

[0030] As an optional implementation, the keywords include time-sensitive keywords and regulatory rule keywords, with the time-sensitive keywords having a higher priority than the regulatory rule keywords.

[0031] Accordingly, the situation where the target service nodes conflict may include: The timeliness of the two service nodes in the target service node pair is inconsistent; and The regulatory rules keywords for the two business nodes in the target business node pair are inconsistent.

[0032] As an optional implementation, the pseudocode for steps S131 to S133 described above can be as follows: def detect_conflict(graph): for node1, node2 in graph.edges: if "timeliness" in node1.attributes and "timeliness" in node2.attributes: if node1.speed != node2.speed and node1.regulatory != node2.regulatory: # Generate a conflict report report = ConflictReport(node1, node2, type="timeliness conflict") trigger_alert(report) In other words, if node 1 and node 2 are two related nodes at the two ends of an edge, and if the timeliness of node 1 is different from that of node 2, a conflict report will be generated.

[0033] As an optional implementation, the conflict report carries the following information: Conflict identification information, information on conflicting business node pairs, and conflict type information.

[0034] In this embodiment of the application, the conflict identification information may be a field that is automatically reviewed for the conflict and can uniquely identify the conflict.

[0035] To facilitate unified management of requirements, optionally, after step S150, the version upgrade method further includes: In step S181, multiple requirement keywords are matched with a set requirement template; In step S182, if there are missing fields in multiple of the required keywords, a field completion notification is generated; In step S183, upon receiving the completion information, a data structure matching the set requirement template is generated using multiple requirement keywords and the completion information. In step S184, the data structure is written into the requirement library.

[0036] After the information is completed, the data structure carrying the demand information is written into the demand database, which is beneficial for subsequent knowledge graph construction and retrieval operations, and expands the use of the demand database.

[0037] In this application embodiment, no special limitation is made on how to obtain the channel to increase demand; optionally, such as Figure 4 As shown, the increased demand for the acquisition channels includes: In step S111, the system interfaces with multiple requirement systems to obtain new requirements from each system. In step S112, the field information of the newly added requirements is identified, and the channels that added requirements are selected.

[0038] Within an enterprise, there may be multiple requirement systems, such as a wiki system, a Jira system, and a DingTalk system.

[0039] In this embodiment of the application, requirements can be periodically crawled from multiple requirement systems using a crawler script or a scheduled task, and then the requirements in various different formats can be identified and channels can be selected to add requirements.

[0040] Optionally, the new requirement carries at least one of the following fields: Demand identification information, source system information, and business entity information.

[0041] As a second aspect of the present invention, an electronic device is provided, such as... Figure 5 As shown, the electronic device includes: One or more processors 101; The storage module 102 stores an executable program that, when invoked by one or more processors 101, enables the version upgrade method described in the first aspect of the present invention.

[0042] The electronic device may also include one or more I / O interfaces 103 connected between the processor 101 and the memory 102, configured to enable information interaction between the processor 101 and the memory 102.

[0043] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, enabling information exchange between the processor and the memory, including but not limited to a data bus (Bus).

[0044] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the electronic device.

[0045] As a third aspect of the present invention, such as Figure 6 As shown, a computer-readable medium is provided, wherein one or more computer programs are stored thereon, which, when invoked, enable the version upgrade method provided by the present invention.

[0046] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. Accordingly, the computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can implement the methods of any of the above embodiments. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0047] These are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the content described in the accompanying drawings and the specific embodiments above. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.

Claims

1. A method for upgrading a cross-border payment system, characterized in that, The version upgrade method includes: Increased demand due to expanded acquisition channels; The increased demand from the aforementioned channels was broken down into multiple demand keywords; Index the business relationship graph using multiple demand keywords; If a conflict report is generated in the business relationship graph where there is a pair of business nodes that conflict with the increased demand from the channel; If there are no business node pairs in the business relationship graph that conflict with the channel expansion requirement, target payment channels are filtered out based on multiple keywords, wherein the target payment channels are payment channels that meet the channel expansion requirement; The target payment channel is verified using a rule verification engine; If the target payment channel meets the compliance verification rules, add an interface corresponding to the target payment channel.

2. The version upgrade method according to claim 1, characterized in that, The method of indexing the business relationship graph using multiple demand keywords includes: Traverse each business node in the business relationship graph and the edges between each business node; Filter out target business node pairs, wherein the target business node pair is a business node pair that simultaneously includes attributes associated with the keyword with the highest priority; If there is a conflict between the target business nodes, it is determined that there is a conflict between the business relationship graph and the channel's increased demand.

3. The version upgrade method according to claim 2, characterized in that, The keywords include time-sensitive keywords and regulatory rule keywords, with time-sensitive keywords having a higher priority than regulatory rule keywords. The target service nodes are subject to conflict in the following situations: The timeliness of the two service nodes in the target service node pair is inconsistent; and The regulatory rules keywords for the two business nodes in the target business node pair are inconsistent.

4. The version upgrade method according to claim 2, characterized in that, The conflict report carries the following information: Conflict identification information, information on conflicting business node pairs, and conflict type information.

5. The version upgrade method according to claim 1, characterized in that, The step of using a rule-based validation engine to validate the target payment channel includes: If the target payment channel meets the timeliness requirements in the channel addition needs, it is matched with the State Administration of Foreign Exchange whitelist according to the bank interface standard of the target payment channel; If the target payment channel's bank interface standard exists in the State Administration of Foreign Exchange's whitelist, the target payment channel is determined to meet the compliance verification rules.

6. The version upgrade method according to any one of claims 1 to 5, characterized in that, If there are no business node pairs in the business relationship graph that conflict with the channel's increased demand, after filtering out the target payment channel based on multiple keywords, the version upgrade method further includes: Match multiple of the aforementioned requirement keywords with the defined requirement template; If there are missing fields in multiple of the aforementioned keyword requirements, a field completion notification will be generated. Upon receiving the completion information, a data structure matching the set requirement template is generated using multiple requirement keywords and the completion information. Write the data structure into the requirements library.

7. The version upgrade method according to any one of claims 1 to 5, characterized in that, The increased demand for the aforementioned acquisition channels includes: Interact with various requirement systems to obtain new requirements from each system; The field information of the newly added requirements is identified, and the channels that added the requirements are selected.

8. The version upgrade method according to claim 7, characterized in that, The new requirement includes at least one of the following fields: Demand identification information, source system information, and business entity information.

9. An electronic device, the electronic device comprising: One or more processors; A storage module storing an executable program, which, when invoked by one or more processors, enables the version upgrade method according to any one of claims 1 to 8.

10. A computer-readable medium, characterized in that, It stores one or more computer programs that, when invoked, can implement the version upgrade method according to any one of claims 1 to 8.

Images