Multi-data source query optimization method and system for cross-border payment risk control

Abstract

The invention relates to the technical field of cross-border payment risk control, in particular to a multi-data source query optimization method for cross-border payment risk control, which comprises the following steps: S1, receiving a cross-border payment transaction request, and analyzing multi-dimensional transaction features; s2, activating an exclusive cache cluster corresponding to the geographic area according to the multi-dimensional transaction characteristics, and dynamically loading high-risk list data of the geographic area after activation; s3, sequentially querying the multi-level cache architecture from low to high according to the access delay, and if the access delay is hit, stopping querying; s4, when all cache levels in the multi-level cache structure are not hit, starting dynamic window concurrency control, and if no matching result exists in the window, sliding the window in sequence and concurrently requesting a subsequent data source; and S5, generating a risk grade score according to a matching result, and writing the newly matched high-risk entity into a regional hotspot cache cluster. According to the invention, the accuracy, real-time performance and resource efficiency of cross-border payment risk prevention and control can be realized, the subsequent data source is concurrently requested through the sliding window, the request frequency is reduced, and the cost is reduced.

Description

Technical Field

[0001] The present invention relates to the field of cross-border payment risk control technology, and in particular to a multi-data source query optimization method, system, device and storage medium for cross-border payment risk control. Background Art

[0002] With the acceleration of globalization and the development of internet technology, cross-border payment transactions have experienced explosive growth. However, the compliance risks they face are becoming increasingly severe. List screening, a core risk management tool for cross-border payments, involves identifying whether transaction participants match regulatory blacklists, sanctions lists, or high-risk entity lists.

[0003] Traditional name list screening relies on sequential or simple combined queries on a single dimension (such as name), failing to meet real-time risk control requirements in high-concurrency scenarios. For example, when combining multiple dimensions like name, address, and ID number, existing systems often experience query latency of hundreds of milliseconds due to inefficient indexing structures (e.g., single-table full scans), making them unable to cope with tens of thousands of concurrent requests. Furthermore, with evolving regulatory requirements (such as the addition of biometric screening dimensions) or a surge in name list data volume, the existing system's centralized architecture and fixed data model struggle to adapt quickly. For example, incorporating new data dimensions like fingerprints and irises requires a complete architecture restructuring, resulting in high development costs and long iteration cycles. Furthermore, the data structure cannot support dynamic scaling and matching across multiple dimensions. Furthermore, existing caching strategies typically employ full caching or simple LRU strategies, failing to optimize for the unique characteristics of cross-border payment transactions (e.g., peak transaction times during specific periods or high-frequency transactions in specific regions). This results in low cache hit rates and frequent access to underlying storage, creating I / O bottlenecks and further exacerbating system latency. Summary of the Invention

[0004] The purpose of the present invention is to address the shortcomings of the prior art and provide a multi-data source query optimization method for cross-border payment risk control, comprising the following steps: S1: Receive a cross-border payment transaction request and analyze multi-dimensional transaction features in the cross-border payment transaction request, including name, ID number, nationality, and geographic location information; S2: Based on the geographic location information, activate the dedicated cache cluster for the corresponding geographic region. After activation, dynamically load the high-risk list data for that geographic region. If the geographic location information is North America, the OFAC SDN list and FinCEN suspicious activity report are preloaded. If the geographic location information is the EU, the EU sanctions list and UK financial sanctions list are preloaded. If the geographic location information is Asia Pacific, the APG high-risk list and ASEAN joint monitoring list are preloaded. S3: querying the multi-level cache architecture in descending order based on the access latency of the high-risk list data, and stopping the query if a hit is found; S4: When all cache levels in the multi-level cache structure do not hit, dynamic window concurrency control is started. If there is no matching result in the window, the window is sequentially slid and concurrent requests are made to subsequent data sources. S5: Generates a risk level score based on the matching results, blocks high-risk transactions and generates alerts, writes newly matched high-risk entities to the regional hotspot cache cluster, and records query patterns for optimizing subsequent cache preloading strategies.

[0005] Preferably, in step S2, dynamically loading the high-risk list data of the geographical area further includes: S21: Based on time series analysis of historical transaction flows, predict regional transaction hotspots within a certain time interval in the future, apply geospatial clustering with preset kilometers to detect regional abnormal activities, and combine with real-time event monitoring to identify sudden financial risk areas; S22: Sort the preloaded regions according to the weighted priority scores, and prioritize loading recent high-frequency list data from CPU registers or high-bandwidth memory.

[0006] Preferably, in step S3, the multi-level cache architecture is queried in sequence from low to high according to the access delay of the high-risk list data, further comprising: S31: querying the high-frequency list hash value in the CPU register cache according to the high-risk list data, and stopping the query if a hit is found; S32: if the CPU register cache does not hit, querying the current processing batch entity ID in the high-bandwidth memory according to the high-risk list data, and stopping the query if a hit is found; S33: if the CPU register cache and the high-bandwidth memory do not hit, querying the entity embedding vector and similarity matrix in the GPU video memory according to the high-risk list data, and stopping the query if a hit is found; S34: if the CPU register cache, the high-bandwidth memory query and the GPU video memory do not hit, querying the complete data of the active sanctions list in the distributed memory database according to the high-risk list data, and stopping the query if a hit is found; S35: If the CPU register cache, the high-bandwidth memory query, the GPU video memory and the distributed memory database do not hit, the historical high-risk list and low-access frequency data in the SSD cache pool are queried based on the high-risk list data, and if a hit is found, the query is stopped.

[0007] Preferably, in step S33, the entity embedding vector and similarity matrix in the GPU memory further include: Convert high-risk entity identification information into BERT embedding vectors; Calculate the cosine similarity between the BERT embedding vector and the high-risk entity vector in GPU memory; When the similarity exceeds the similarity threshold, it is determined as a cache hit, and the vector comparison operation is processed in parallel through the CUDA kernel function.

[0008] Preferably, in step S4, starting dynamic window concurrency control further includes: S41: Initialize the window size to N and concurrently request the first N external list data sources; S42: Monitor the returned results in real time. When any data source returns a matching result, immediately terminate all ongoing query requests and cancel any subsequent data source queries that have not yet been initiated. S43: If there is no matching result in the window, the window is sequentially slid and subsequent data sources are concurrently requested.

[0009] Preferably, in step S5, writing the newly matched high-risk entity into the regional hotspot cache cluster further includes: When the system detects multiple consecutive transactions of the same type in the same region, it automatically increases the preloading priority of the cache cluster in that region. When the external data source returns a new high-risk entity, it is injected into the corresponding regional cache cluster; the index structure of each layer in the five-level cache is updated and synchronized to all regional routing nodes.

[0010] Preferably, real-time hotspot migration is also included: Execute the regional hotspot detection algorithm every minute; When the popularity score of a new region exceeds that of an existing cache region, a dedicated cache node for that region is automatically created, region-specific data is loaded from the central list library, and the global routing table is updated to point to the new node.

[0011] Based on the same concept, the present invention also provides a multi-data source query optimization system for cross-border payment risk control, including: a parsing module, receiving a cross-border payment transaction request and parsing the multi-dimensional transaction features in the cross-border payment transaction request, including name, ID number, nationality, and geographic location information; A list data loading module activates a dedicated cache cluster for a specific geographic region based on the multi-dimensional transaction characteristics. Upon activation, it dynamically loads the high-risk list data for that geographic region. If the geographic location is North America, it preloads the OFAC SDN list and FinCEN Suspicious Activity Report. If the geographic location is the EU, it preloads the EU Sanctions List and the UK Financial Sanctions List. If the geographic location is Asia Pacific, it preloads the APG High-Risk List and the ASEAN Joint Monitoring List. The multi-level cache query module queries the multi-level cache architecture in order from low to high access latency, and stops the query if a hit is found; A sliding window request module, which starts dynamic window concurrency control when all cache levels in the multi-level cache structure do not hit, and if there is no matching result in the window, sequentially slides the window to concurrently request subsequent data sources; The entity update module generates a risk level score based on the matching results, blocks high-risk transactions and generates alerts, writes newly matched high-risk entities to the regional hotspot cache cluster, and records query patterns for optimizing subsequent cache preloading strategies.

[0012] Based on the same concept, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor executes the steps of the multi-data source query optimization method for cross-border payment risk control as described in any one of the embodiments.

[0013] Based on the same concept, the present invention also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the multi-data source query optimization method for cross-border payment risk control as described in any one of the embodiments.

[0014] Compared with the prior art, the present invention has the following beneficial effects: The present invention receives a cross-border payment transaction request, parses the multi-dimensional transaction features in the cross-border payment transaction request, including name, ID number, nationality and geographic location information, activates the exclusive cache cluster of the corresponding geographical area according to the multi-dimensional transaction features, and dynamically loads the high-risk list data of the geographical area after activation, thereby realizing cache cluster activation and dynamic list loading based on geographical area perception, and achieving accuracy, real-timeness and resource efficiency in cross-border payment risk prevention and control.

[0015] The present invention queries the multi-level cache architecture in descending order based on the access latency of high-risk list data. If a hit is found, the query stops. When all cache levels in the multi-level cache structure miss, dynamic window concurrency control is activated. If there is no matching result in the window, the window is slid sequentially to concurrently request subsequent data sources, reducing the number of requests and lowering costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Various other advantages and benefits will become apparent to those skilled in the art by reading the following detailed description of the preferred embodiment.The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the invention.

[0017] Figure 1 This is a flow chart of the multi-data source query optimization method for cross-border payment risk control of the present invention; Figure 2This is a sliding window flow chart of the multi-data source query optimization method for cross-border payment risk control of the present invention. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Obviously, the embodiments described are part of the embodiments of this application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without making creative work are within the scope of protection of this application.

[0019] Those skilled in the art will understand that, unless otherwise specified, the singular forms "a," "an," and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present invention refers to the presence of the stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0020] First embodiment See also Figure 1 As shown, this embodiment provides a multi-data source query optimization method for cross-border payment risk control, including the following steps: S1: Receive a cross-border payment transaction request, and parse the multi-dimensional transaction features in the cross-border payment transaction request, including name, ID number, nationality, and geographic location information. Specifically, in this embodiment, the cross-border payment transaction request is in JSON data format. Check whether JSON fields such as name, ID number, nationality, and geographic location information are missing, verify whether the ID number complies with the standards of various countries (such as 18 digits for Chinese ID cards and 9 digits for US SSNs), and whether the coordinates of the geographic location information are valid longitude and latitude (such as latitude ±90° and longitude ±180°).

[0021] S2: Based on multi-dimensional transaction characteristics, the dedicated cache cluster for the corresponding geographic region is activated. After activation, the high-risk list data for that geographic region is dynamically loaded. If the geographic location information is North America, the OFAC SDN list and FinCEN suspicious activity report are preloaded. If the geographic location information is the EU region, the EU sanctions list and UK financial sanctions list are preloaded. If the geographic location information is the Asia-Pacific region, the APG high-risk list and ASEAN joint monitoring list are preloaded. Specifically, in this embodiment, the GeoHash algorithm converts the latitude and longitude of the geographic location into a string, and quickly locates it through prefix matching. For high-frequency trading areas (such as Asia-Pacific), a scheduled task is used to preload the high-risk list into the cache (for example, updating it at 3:00 a.m. every day) to avoid cache penetration during peak trading times. For low-frequency areas (such as Africa), a lazy loading mode is adopted, and the corresponding cache cluster is only activated for the first transaction request, saving memory resources.

[0022] Preferably, in step S2, dynamically loading the high-risk list data of the geographical area further includes: S21: Based on time series analysis of historical transaction flows, regional transaction hotspots within several time intervals in the future are predicted. Preset kilometer-wide geospatial clustering is applied to detect regional abnormal activities. Combined with real-time event monitoring, sudden financial risk areas are identified. Specifically, in this embodiment, features such as historical transaction timestamps (e.g., aggregated by hour / day), geographic coordinates (latitude and longitude), and transaction amounts / frequency are extracted to construct a time series dataset. Based on an LSTM neural network, the periodicity of transaction frequency is captured to predict regional transaction hotspots within the next four hours. DBSCAN or HDBSCAN is used to cluster geographic coordinates, with a radius threshold of 5 kilometers set to identify densely traded areas. High-frequency transaction areas use a smaller radius (5 kilometers), while low-frequency areas use a larger radius (20 kilometers). External data sources (e.g., news APIs, government announcements) are accessed. If events such as "sudden coup in a certain country" or "regional banking system failure" are detected, the corresponding area is automatically marked as high-risk, overwriting the original prediction model results. S22: Sort the preloaded regions according to the weighted priority scores, and prioritize loading recent high-frequency list data from the CPU register or high-bandwidth memory. Specifically, in this embodiment, the weighted priority scores are calculated based on recent transaction frequency, risk level, predicted hot spot probability, and cache access history.

[0023] S3: Query the multi-level cache architecture in order from low to high according to the access latency of the high-risk list data. If a hit is found, the query is stopped. Specifically, in this embodiment, the hot area is stored in the CPU register and high-bandwidth memory, and the GPU video memory stores the non-hot area, and the distributed memory database and SSD cache pool store cold data.

[0024] Preferably, in step S3, the multi-level cache architecture is queried in sequence from low to high according to the access latency, further comprising: S31: querying the hash value of the high-frequency list in the CPU register cache, and stopping the query if a hit is found. Specifically, in this embodiment, the entity ID hash value of the high-frequency list is extracted; S32: if the CPU register cache does not hit, querying the entity ID of the current processing batch in the high-bandwidth memory, and stopping the query if a hit is found. Specifically, in this embodiment, a Bloom filter is used to store the entity ID of the current processing batch; S33: if the CPU register cache and the high-bandwidth memory do not hit, querying the entity embedding vector and similarity matrix in the GPU video memory, and stopping the query if a hit is found. Specifically, in this embodiment, the input name is converted into an embedding vector, transferred to the GPU memory in batches, 1024 CUDA threads are started to calculate the similarity in parallel, and the top 10 high matching results are taken and returned; S34: If the CPU register cache, high-bandwidth memory query, and GPU video memory do not hit, the complete data of the active sanctions list in the distributed memory database is queried. If a hit is found, the query is stopped. Specifically, in this embodiment, RedisCluster or Apache Ignite is used, and hash sharding is performed by entity ID; S35: If the CPU register cache, high-bandwidth memory query, GPU video memory, and distributed memory database do not hit, the historical high-risk list and low-access frequency data in the SSD cache pool are queried. If a hit is found, the query is stopped. Specifically, in this embodiment, the historical list is stored in Parquet format columnarly, partitioned by year + region (such as / data / sanctions / 2023 / APAC), supports fast scanning, establishes an inverted index (such as a name initial index), and optimizes write performance through the SSD's TRIM instruction.

[0025] Preferably, in step S33, the entity embedding vector and similarity matrix in the GPU memory further include: Convert high-risk entity identification information into BERT embedding vectors. Specifically, in this embodiment, a word segmenter is used to split long words into subwords to improve OOV (out-of-view) processing capabilities; Calculate the cosine similarity between the BERT embedding vector and the high-risk entity vector in the GPU memory. Specifically, in this embodiment, the generated embedding vector needs to be L2 normalized to ensure that the cosine similarity calculation is equivalent to the vector dot product; When the similarity exceeds the similarity threshold, it is determined as a cache hit. The vector comparison operation is processed in parallel through the CUDA kernel function. Specifically, in this embodiment, CUDA's Pitch Linear memory is used to store the embedded vector matrix. Each row corresponds to an entity, and 128 float type elements are stored continuously to facilitate batch reading by row.

[0026] S4: When all cache levels in the multi-level cache structure miss, dynamic window concurrency control is started. If there is no matching result in the window, the window is slid in sequence to concurrently request subsequent data sources. Specifically, in this embodiment, when the initial window misses or some requests fail, the next data source is added in sequence to form a new window. The window is expanded strictly in the order of data source delay to avoid high-latency interfaces (such as third-party APIs) from joining the window too early. The window size does not exceed the system's maximum concurrency threshold (such as 5 threads) to prevent resource exhaustion. An independent timeout is set for each data source (such as 500ms for HDFS and 3s for third-party APIs). Timed-out requests automatically fail without blocking other requests in the window. For idempotent requests (such as database queries), they are retried once within the current window after failure; for non-idempotent requests (such as API calls), they are only tried once.

[0027] Preferably, in step S4, starting dynamic window concurrency control further includes: S41: Initialize the window size to N and concurrently request the first N external list data sources. Specifically, in this embodiment, the initial window size is 3. The value of N is adjusted based on the average response time of the previous window. If the average delay is less than 50ms, N+=1 (expand the window to speed up the query). If the average delay is greater than 200ms, N-=1 (reduce the window to reduce resource pressure). Data sources with frequent failures are automatically lowered in priority and added to the window after a sliding delay. S42: Monitor the returned results in real time. When any data source returns a matching result, immediately terminate all ongoing query requests and cancel any subsequent data source queries that have not yet been initiated. S43: If there is no matching result in the window, the window is sequentially slid and subsequent data sources are concurrently requested.

[0028] S5: Generate a risk level score based on the matching results, block high-risk transactions and generate an alert, write the newly matched high-risk entity into the regional hotspot cache cluster, and record the query pattern for optimizing the subsequent cache preloading strategy. Specifically, in this embodiment, a risk score is generated based on the similarity of the matching results, the credibility of the data source, historical risk records and other dimensions. If the score range is 0-39, it is risk-free and released normally. If the score range is 40-59, it is low risk and a log is recorded. The transaction is allowed but marked as a monitored object. If the score range is 60-79, it is medium risk and a log is recorded. The funds are frozen for 2 hours and multi-factor authentication is triggered. If the score range is 80-100, it is high risk and the transaction is immediately blocked and manually reviewed and the regional hotspot cache is updated.

[0029] Preferably, in step S5, writing the newly matched high-risk entity into the regional hotspot cache cluster further includes: When the system detects multiple consecutive transactions of the same type in the same region, it automatically increases the preloading priority of the cache cluster in that region. When the external data source returns a new high-risk entity, it is injected into the corresponding regional cache cluster; the index structure of each layer in the five-level cache is updated and synchronized to all regional routing nodes.

[0030] Preferably, real-time hotspot migration is also included: The regional hotspot detection algorithm is executed every minute. Specifically, in this embodiment, the real-time popularity score of each region is calculated based on a combination of transaction frequency, risk event density, query hit rate, and other dimensions. The data from the past 60 seconds is counted based on a sliding window. When the popularity score of a new region exceeds that of an existing cache region, a dedicated cache node for that region is automatically created, region-specific data is loaded from the central list library, and the global routing table is updated to point to the new node.

[0031] Second embodiment Based on the same concept, the present invention also provides a multi-data source query optimization system for cross-border payment risk control, including: a parsing module, receiving a cross-border payment transaction request and parsing the multi-dimensional transaction features in the cross-border payment transaction request, including name, ID number, nationality, and geographic location information; A list data loading module activates a dedicated cache cluster for a specific geographic region based on the multi-dimensional transaction characteristics. Upon activation, it dynamically loads the high-risk list data for that geographic region. If the geographic location is North America, it preloads the OFAC SDN list and FinCEN Suspicious Activity Report. If the geographic location is the EU, it preloads the EU Sanctions List and the UK Financial Sanctions List. If the geographic location is Asia Pacific, it preloads the APG High-Risk List and the ASEAN Joint Monitoring List. The multi-level cache query module queries the multi-level cache architecture in order from low to high access latency, and stops the query if a hit is found; A sliding window request module, which starts dynamic window concurrency control when all cache levels in the multi-level cache structure do not hit, and if there is no matching result in the window, sequentially slides the window to concurrently request subsequent data sources; The entity update module generates a risk level score based on the matching results, blocks high-risk transactions and generates alerts, writes newly matched high-risk entities to the regional hotspot cache cluster, and records query patterns for optimizing subsequent cache preloading strategies.

[0032] Third embodiment In some embodiments of the present application, a computer device is also provided, including a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor performs the steps of the multi-data source query optimization method for cross-border payment risk control as described in any one of the embodiments.

[0033] The present invention also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the multi-data source query optimization method for cross-border payment risk control as described in any one of the first embodiments.

[0034] Based on the same concept, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor performs the steps of multi-data source query optimization for large cross-border payment risk control as described in any one of the embodiments.

[0035] It is understandable that, for the aforementioned cross-border payment risk control multi-data source query optimization, if it is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer server, or a network device, etc.) to execute all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program code.

[0036] Computer-readable storage media may include a data signal propagated in baseband or as part of a carrier wave, which carries readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination thereof.

[0037] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiment. All technical solutions based on the concept of the present invention are within the scope of protection of the present invention. It should be noted that for those skilled in the art, various improvements and modifications that do not depart from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A multi-data source query optimization method for cross-border payment risk control, characterized in that: The following steps are involved: S1: Receive a cross-border payment transaction request and analyze multi-dimensional transaction features in the cross-border payment transaction request, including name, ID number, nationality, and geographic location information; S2: Based on the multi-dimensional transaction characteristics, a dedicated cache cluster for the corresponding geographic region is activated. After activation, the high-risk list data for that geographic region is dynamically loaded. If the geographic location information is North America, the OFAC SDN list and FinCEN suspicious activity report are pre-loaded. If the geographic location information is the EU, the EU sanctions list and UK financial sanctions list are pre-loaded. If the geographic location information is the Asia-Pacific region, the APG high-risk list and ASEAN joint monitoring list are pre-loaded. S3: querying the multi-level cache architecture in descending order based on the access latency of the high-risk list data, and stopping the query if a hit is found; S4: When all cache levels in the multi-level cache structure do not hit, dynamic window concurrency control is started. If there is no matching result in the window, the window is sequentially slid and concurrent requests are made to subsequent data sources. S5: Generates a risk level score based on the matching results, blocks high-risk transactions and generates alerts, writes newly matched high-risk entities to the regional hotspot cache cluster, and records query patterns for optimizing subsequent cache preloading strategies.

2. The multi-data source query optimization method for cross-border payment risk control according to claim 1 is characterized in that: In step S2, dynamically loading the high-risk list data for the geographical area further includes: S21: Based on time series analysis of historical transaction flows, predict regional transaction hotspots within a certain time interval in the future, apply geospatial clustering with preset kilometers to detect regional abnormal activities, and combine with real-time event monitoring to identify sudden financial risk areas; S22: Sort the preloaded regions according to the weighted priority scores, and prioritize loading recent high-frequency list data from CPU registers or high-bandwidth memory.

3. The multi-data source query optimization method for cross-border payment risk control according to claim 2 is characterized in that: In step S3, a multi-level cache architecture is queried sequentially from low to high according to the access latency of the high-risk list data, further comprising: S31: querying the high-frequency list hash value in the CPU register cache according to the high-risk list data, and stopping the query if a hit is found; S32: if the CPU register cache does not hit, querying the current processing batch entity ID in the high-bandwidth memory according to the high-risk list data, and stopping the query if a hit is found; S33: if the CPU register cache and the high-bandwidth memory do not hit, querying the entity embedding vector and similarity matrix in the GPU memory according to the high-risk list data, and stopping the query if a hit is found; S34: if the CPU register cache, the high-bandwidth memory query, and the GPU memory do not hit, querying the complete data of the active sanctions list in the distributed memory database according to the high-risk list data, and stopping the query if a hit is found; S35: if the CPU register cache, the high-bandwidth memory query, the GPU memory, and the distributed memory database do not hit, querying the historical high-risk list and low-access frequency data in the SSD cache pool according to the high-risk list data, and stopping the query if a hit is found.

4. The multi-data source query optimization method for cross-border payment risk control according to claim 3 is characterized in that: In step S33, the entity embedding vector and similarity matrix in the GPU memory further include: Convert high-risk entity identification information into BERT embedding vectors; Calculate the cosine similarity between the BERT embedding vector and the high-risk entity vector in GPU memory; When the similarity exceeds the similarity threshold, it is determined as a cache hit, and the vector comparison operation is processed in parallel through the CUDA kernel function.

5. The multi-data source query optimization method for cross-border payment risk control according to claim 4 is characterized in that: In step S4, dynamic window concurrency control is started, further comprising: S41: Initialize the window size to N and concurrently request the first N external list data sources; S42: Monitor the returned results in real time. When any data source returns a matching result, immediately terminate all ongoing query requests and cancel any subsequent data source queries that have not yet been initiated. S43: If there is no matching result in the window, the window is sequentially slid and subsequent data sources are concurrently requested.

6. The multi-data source query optimization method for cross-border payment risk control according to claim 5 is characterized in that: In step S5, the newly matched high-risk entity is written into the regional hotspot cache cluster, further comprising: When the system detects multiple consecutive transactions of the same type in the same region, it automatically increases the preloading priority of the cache cluster in that region. When the external data source returns a new high-risk entity, it is injected into the corresponding regional cache cluster; the index structure of each layer in the five-level cache is updated and synchronized to all regional routing nodes.

7. The multi-data source query optimization method for cross-border payment risk control according to claim 6 is characterized in that: Also includes live hotspot migration: Execute the regional hotspot detection algorithm every minute; When the popularity score of a new region exceeds that of an existing cache region, a dedicated cache node for that region is automatically created, region-specific data is loaded from the central list library, and the global routing table is updated to point to the new node.

8. A multi-data source query optimization system for cross-border payment risk control, characterized by: include: a parsing module, receiving a cross-border payment transaction request and parsing the multi-dimensional transaction features in the cross-border payment transaction request, including name, ID number, nationality, and geographic location information; A list data loading module activates a dedicated cache cluster for a specific geographic region based on the multi-dimensional transaction characteristics. Upon activation, it dynamically loads the high-risk list data for that geographic region. If the geographic location is North America, it preloads the OFAC SDN list and FinCEN Suspicious Activity Report. If the geographic location is the EU, it preloads the EU Sanctions List and the UK Financial Sanctions List. If the geographic location is Asia Pacific, it preloads the APG High-Risk List and the ASEAN Joint Monitoring List. A multi-level cache query module queries the multi-level cache architecture in descending order based on the access latency of the high-risk list data, and stops the query if a hit is found; A sliding window request module, which starts dynamic window concurrency control when all cache levels in the multi-level cache structure do not hit, and if there is no matching result in the window, sequentially slides the window to concurrently request subsequent data sources; The entity update module generates a risk level score based on the matching results, blocks high-risk transactions and generates alerts, writes newly matched high-risk entities to the regional hotspot cache cluster, and records query patterns for optimizing subsequent cache preloading strategies.

9. A computer device, characterized in that: It includes a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor performs the steps of the multi-data source query optimization method for cross-border payment risk control according to any one of claims 1 to 8.

10. A storage medium storing computer-readable instructions, characterized in that: When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the multi-data source query optimization method for cross-border payment risk control according to any one of claims 1 to 8.

Images