Overlay Network for Real-Time Payment Network

Abstract

Various embodiments are disclosed for facilitating settlement between members of separate settlement networks. A first instance of a supernetwork can be connected to the first supernetwork instance and can receive a settlement request from an originating network hub linked to the first settlement network, the first settlement request specifying an identifier of a recipient institution and an amount of the settlement request. The first instance of the supernetwork can then query a subscriber status cache to identify a destination network hub linked to a second settlement network associated with the recipient institution. The first instance of the supernetwork can then query a subscriber registry to identify a second supernetwork instance connected to the destination network hub. Finally, the first instance of the supernetwork can forward the settlement request to a second global transaction router hosted by a second supernetwork instance connected to the destination network hub.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and benefit of co-pending U.S. patent application Ser. No. 18 / 091,097, filed Dec. 29, 2022, entitled "OVERLAY NETWORK FOR REAL-TIM PAYMENT NETWORKS," which is incorporated by reference in its entirety as if set forth herein. [Background technology]

[0002] Financial institutions use real-time settlement networks to transfer funds to other participating financial institutions in real time or near real time. Financial institutions may also be members of other types of settlement networks. Financial institutions may also be members of multiple settlement networks to offer multiple payment options to their customers and to enhance the financial institution's ability to make electronic payments to other financial institutions. [Brief explanation of the drawings]

[0003] Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the disclosure. Moreover, in the drawings, like reference numerals indicate corresponding parts throughout the several views.

[0004] [Figure 1] FIG. 1 illustrates a real-time payment network according to various embodiments of the present disclosure. [Figure 2] FIG. 1 illustrates a super-network in accordance with various embodiments of the present disclosure. [Figure 3] 3 is a flowchart illustrating an example of functionality implemented as part of an application running in a computing environment in the super-network of FIG. 2, according to various embodiments of the present disclosure. [Figure 4]3 is a flowchart illustrating an example of functionality implemented as part of an application running in a computing environment in the super-network of FIG. 2, according to various embodiments of the present disclosure. [Figure 5] 3 is a flowchart illustrating an example of functionality implemented as part of an application running in a computing environment in the super-network of FIG. 2, according to various embodiments of the present disclosure. [Figure 6] 3 is a flowchart illustrating an example of functionality implemented as part of an application running in a computing environment in the super-network of FIG. 2, according to various embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0005] Various techniques are disclosed for connecting different real-time payment networks and facilitating settlements between them. Financial institutions are often members of real-time payment (RTP) networks to enable real-time settlements between financial institutions. In general, two financial institutions can make real-time payments with each other as long as they are members of the same RTP network.

[0006] However, there are multiple RTP networks currently available. If two financial institutions are not members of or in the same RTP network, they cannot make real-time payments to each other. This can occur when multiple RTP networks are available within the same jurisdiction (e.g., FedNow and THE CLEARING HOUSE in the United States) or when financial institutions are located in different jurisdictions that offer different RTP networks due to differences in regulations and oversight. Thus, various embodiments of the present disclosure solve a problem that arises when a first financial institution that is a member of a real-time payment network wants to make a real-time payment to a second financial institution that is not a member of the real-time payment network.

[0007] The following description provides an overview of the system and its components, followed by a description of their operation. While the following description provides examples of the operation of various components of the present disclosure, use of the following examples does not exclude other implementations that are consistent with the principles disclosed by the following examples.

[0008] 1 is a schematic block diagram illustrating an example of a real-time settlement (RTP) network 100. RTP network 100 is a settlement rail or network that allows member institutions to make settlements to each other instantly at any time, unlike other settlement rails or networks where settlements may take several days to process and / or can only be made or processed on certain days or times (e.g., only on business days and / or only on business hours). Examples of RTP networks 100 in the United States are the THE CLEARING HOUSE RTP network provided by The Clearing House and the FEDNOW RTP network provided by the Federal Reserve. Other RTP networks 100 are available in other jurisdictions.

[0009] RTP 100 may have several components, such as one or more subscriber systems 103 (e.g., subscriber system 103a, subscriber system 103b, subscriber system 103c, subscriber system 103d, etc.) and network hub 106. Subscriber systems 103 represent systems owned or operated by members of RTP network 100, such as banks or other financial institutions, that use RTP network 100 to send and receive payments in real time. Network hub 106 may represent one or more computing systems and software services that receive and coordinate payment requests from subscriber systems 103.

[0010] Thus, the network hub 106 may store various data that enables the network hub 106 to facilitate payments from one network subscriber 103 to another network subscriber 103 and route payments from a network subscriber 103 of an RTP network 100 to another network subscriber 103 of another RTP network 100 using the super network 200 (FIG. 2). This data may include a network identifier 109 and one or more subscriber accounts 113.

[0011] The network identifier 109 may represent any identifier that uniquely identifies the RTP network 100 relative to another RTP network 100. The network identifier 109 may be used by the super network 200 to identify or distinguish between individual RTP networks 100 when routing payments between the RTP networks 100.

[0012] The network hub 106 can use the subscriber account 113 to track the amount of funds for each subscriber system 103 that has deposits in the RTP network 100. Thus, each subscriber system 103 of a subscriber can be associated with a subscriber account 113. The subscriber account 113 can include information such as a subscriber identifier 116 and a balance 119. The subscriber identifier 116 can be any identifier that uniquely identifies a subscriber system 103, and therefore a subscriber, to another subscriber system 103, and therefore another subscriber. The balance 119 can represent the amount of funds in the subscriber account 113 available to the respective subscriber. When a settlement request is sent by a first subscriber system 103, the amount of the balance 119 in the subscriber account 113 associated with the first subscriber system 103 is reduced by the amount specified in the settlement request. Meanwhile, the amount of the balance 119 in the subscriber account 113 of the second, receiving subscriber system 103 is increased by the amount specified in the settlement request.

[0013] The operator of the super network 200 may also maintain the RTP network 100 subscriber account 113. As described in more detail below, the super network 200 subscriber account 113 may be used by the super network 200 to facilitate payments between members of the RTP network 100 and members of other RTP networks 100.

[0014] 2 is a schematic block diagram illustrating an example of a super-network 200 in accordance with various embodiments of the present disclosure. The super-network 200 can be implemented to route payments between different RTP networks 100 (FIG. 2), thereby enabling subscribers of a first RTP network 100 to make real-time payments to subscribers of a separate, second RTP network 100. Accordingly, the super-network 200 can include one or more super-network instances 203, such as super-network instance 203a and super-network instance 203b, that form a peer-to-peer network with each other. Each super-network instance 203 can be in data communication with one or more network hubs 106, such as network hubs 106a, 106b, 106c, 106d, 106e, 106f, 106g, and 106h.

[0015] Each super network instance 203 may include several components. For example, a super network instance 203 may include a global transaction router 206, a subscriber status cache 209, a subscriber registry 211, and a transaction ledger 213. The global transaction router 206 is operable to route settlement requests between network hubs 106 of different RTP networks 100 connected to the super network instance 203.

[0016] The subscriber status cache 209, subscriber registry 211, and transaction ledger 213 all represent data stores associated with the operation of various applications or functional entities in various embodiments of the present disclosure. The subscriber status cache 209, subscriber registry 211, and transaction ledger 213 can be implemented as relational or non-relational databases, such as object-oriented databases, hierarchical databases, hash tables, or similar key-value data stores, as well as other data storage applications or data structures. Also, combinations of these databases, data storage applications, and / or data structures may be used together to provide a single logical data store. In many instances of the present disclosure, the subscriber status cache 209, subscriber registry 211, and transaction ledger 213 can be implemented as distributed, eventually consistent data stores to synchronize data across multiple super network instances 203. The subscriber status cache 209 can include one or more subscriber records 216. The subscriber registry 211 can store RTP registration data 217. Meanwhile, the transaction ledger 213 can include one or more transaction records 219. As needed for various embodiments of the present disclosure, other data may also be stored in the subscriber status cache 209, subscriber repository 211, or transaction ledger 213. Also, although shown separately, the data stored in the subscriber status cache 209, subscriber registry 211, and transaction ledger 213 may be combined into one or more data stores in some implementations.

[0017] The subscriber records 216 represent records of subscriber systems 103 that are members of an RTP network 100. Each subscriber record 216 may include the network identifier 109 of the RTP network 100 of which the subscriber system 103 is a member, as well as the subscriber identifier 116 of the subscriber system 103 in that RTP network 100. If a subscriber or subscriber system 103 is a member or subscriber in multiple RTP networks 100, the subscriber or subscriber system 103 may be associated with multiple subscriber records 216. Other information may also be included in the subscriber record 216 as needed for a particular implementation of the present disclosure.

[0018] The RTP registration data 217 includes information about individual RTP networks 100 that have network hubs 106 connected to supernetwork instances 203 of the supernetwork. The RTP registration data 217 may include a list of network hubs 106 or RTP networks 100 and the individual supernetwork instances 203 to which the network hubs 106 are connected or in data communication. For example, the RTP registration data 217 may map the network identifier 109 of an RTP network 100 to a particular supernetwork instance 203 (e.g., using the instance identifier of the supernetwork instance 203). Other information about individual RTP networks 100 may also be stored in the RTP registration data 216 as needed for particular implementations of the present disclosure.

[0019] The transaction record 219 may represent a record of a transaction conducted between subscribers of two different RTP networks 100 within the super network 200. Information stored in the transaction record 219 may include the payer's subscriber identifier 116 and network identifier 109, the payee's subscriber identifier 116 and network identifier 109, the transaction amount, and any other information that may be relevant to a particular embodiment of the present disclosure.

[0020] The operation of the various components of super-network 200 will now be generally described. The following description illustrates only one example of the operation of super-network 200 and the interactions between the individual components, although other interactions and operations may occur in accordance with various embodiments of the present disclosure. A more detailed description of the operation of the individual components is provided in the flowcharts of Figures 3-6.

[0021] First, a network hub 106 of an RTP network 100 can be configured to connect to a supernetwork instance 203 of a supernetwork 200. As part of the connection process, the network hub 106 can be configured to send and receive messages to and from the supernetwork instance 203 using a supernetwork-compliant message protocol. The network hub 106 can also be configured to convert payment messages from the format of the RTP network 100 served by the network hub 106 to the supernetwork-compliant message protocol, and vice versa. Also, upon registration or initial connection of the network hub 106 of the RTP network 100 to the supernetwork instance 203, RTP registration data 217 of the RTP network 100 can be stored in a subscriber registry 211. For example, the network identifier 109 of the RTP network 100 can be stored in association with the instance identifier of the supernetwork instance 203 to which the network hub 106 is connected. The subscriber registry 211 can then replicate, distribute, or synchronize the RTP registration data to other subscriber registries 211 of other supernetwork instances 203.

[0022] The network hub 106 may then provide a list of all subscribers in the RTP network 100 of the network hub 106 to the global trading router 206 of the super network instance 203, which may include the network identifier 109 of the RTP network 100 of the network hub 106 as well as the subscriber identifiers 116 of the subscriber systems 103 of the RTP network 100 of the network hub 106. In response, the global trading router 206 may create and store in the subscriber status cache 209 a subscriber record 216 for each of the subscribers in the RTP network 100 of the network hub 106. The subscriber status cache 209 may then replicate, distribute, or synchronize the newly created subscriber records 216 to other subscriber status caches 209 of other super network instances 203.

[0023] A network hub 106 (e.g., network hub 106a) of the first RTP network 100 may then receive the settlement request from the subscriber system 103 and send the settlement to a second subscriber system 103 that is part of the second RTP network 100 using a second network hub 106 (e.g., network hub 106h). The first network hub 106a may determine that the recipient of the transaction is not a member of the first RTP network 100. In response, the first network hub 106a may create and send a settlement request to a global transaction router 206a executed by the super network instance 203a to which the network hub 106a is connected.

[0024] The global transaction router 206a can evaluate the settlement request to determine where to route it. For example, the global transaction router 206a can query the subscriber status cache 209 to determine whether there is a subscriber record 216 that matches the recipient's subscriber identifier 116. If a subscriber record 216 exists, the global transaction router 206a can retrieve the network identifier 109 to determine which network hub 106 to route the settlement request to. If the network identifier 109 does not match the network identifier 109 of a network hub 106 connected to the supernetwork instance 203a, the global transaction router 206a can query the RTP registration data 217 in the subscriber registry 211a to determine which supernetwork instance 203 (e.g., supernetwork instance 203b) to route the settlement request to. The global transaction router 206a can then send the settlement request to the appropriate global transaction router 206b.

[0025] The global transaction router 206b may receive the settlement request and evaluate the settlement request to determine which network hub 106 to route the settlement request to. For example, the global transaction router 206b may compare the network identifier 109 specified in the settlement request with the network identifiers 109 of the network hubs 106 connected to the super network instance 203b. If the network identifier 109 in the settlement request matches the network identifier 106 of a connected network hub 106, such as network hub 106h, the global transaction router 206b may forward the settlement request to the recipient network hub 106h.

[0026] The recipient network hub 106h can send a response message back to the global transaction router 206b accepting or rejecting the settlement request, which can then relay the response message to the global transaction router 206a, which can relay the response message to the originating network hub 106a.

[0027] Referring now to Figure 3, a flowchart is shown illustrating one example of the operation of a portion of network hub 106. The flowchart of Figure 3 is merely one example of many different types of functional configurations that can be employed to implement the operation of the illustrated portion of network hub 106. Alternatively, the flowchart of Figure 3 can be viewed as illustrating one example of elements of a method implemented within RTP network 100 or super-network 200.

[0028] Beginning at block 303, the network hub 106 may receive a payment request from a subscriber system 103. The payment request may include information such as the recipient subscriber identifier 116, the payee subscriber identifier 116, the payment amount, and possibly other information.

[0029] Next, in block 306, the network hub 106 may determine whether the balance 119 of the subscriber account 113 associated with the subscriber identifier 116 of the payee who submitted the payment request in block 303 has sufficient funds to complete the payment. If the balance 119 of the subscriber account 113 does not have sufficient funds to complete the payment, the process may end. Optionally, the network hub 106 may send a denial or error message to the subscriber system that submitted the payment request. However, if the balance 119 of the subscriber account 113 has sufficient funds, the process may proceed to block 309.

[0030] Moving to block 309, the network hub 106 may determine whether the recipient identified in the payment request is a subscriber in the RTP network 100. For example, the network hub 106 may search for a subscriber account 113 having a subscriber identifier 116 that matches the subscriber identifier 116 specified in the payment request. If a matching subscriber account 113 is found, the network hub 106 may determine that the recipient is a member of the RTP network 100, and the process may proceed to block 313. However, if a matching subscriber account 113 is not found, this may indicate that the recipient is not a member of the RTP network 100. In this situation, the process may proceed to block 319.

[0031] If the process proceeds to block 313, the network hub 106 may adjust the account balance 119 of the payer's subscriber account 113. For example, the network hub 106 may subtract from the account balance 119 an amount of funds equal to the amount of funds specified in the payment request.

[0032] Next, in block 316, the network hub 106 may similarly adjust the account balance 119 of the recipient's subscriber account 113. For example, the network hub 106 may add to the recipient's account balance 119 an amount of funds equal to the amount of funds specified in the settlement request.

[0033] However, if the process instead proceeds to block 319, the network hub 106 may place a hold on the account balance 119 of the payer subscriber account 113 that submitted the payment request in block 303. This hold may be made to prevent double spending of funds held in the payer subscriber account 113 while the network hub 106 forwards the payment request to the global transaction router 206 of the super network instance 203.

[0034] Next, in block 323, the network hub 106 may forward the settlement request to a global transaction router 206 of the super network instance 203 to which the network hub 106 is connected. In some implementations, the network hub 106 may create a new settlement message or settlement request that meets any protocol requirements of the super network 200. Generally, such a new settlement message or settlement request will contain at least the same information contained in the original settlement, but will be formatted in a standardized manner that can be processed by the global transaction router 206.

[0035] Moving to block 326, the network hub 106 may wait until it receives a settlement response message from the global transaction router 206 of the super network instance 203 to which the network hub 106 is connected. Once the settlement response message is received, the network hub 106 may analyze the settlement response message to determine whether the settlement request was accepted by the recipient network hub 106 or whether the settlement request was rejected. If the settlement response message indicates that the settlement request was accepted, the process may proceed to block 329. However, if the settlement response message indicates that the settlement request was rejected, the process may skip to block 336.

[0036] If the process proceeds to block 329, the network hub 106 may adjust the payer account balance 119. For example, the network hub 106 may deduct from the account balance 119 an amount of funds equal to the amount specified in the settlement request. In some cases, the settlement response message may include an additional transaction fee (e.g., a transaction fee required by the super network 200 or the recipient network hub 106 to process the settlement). In such cases, the additional transaction fee may also be deducted from the account balance 119 of the payer subscriber account 113.

[0037] Next, in block 333, the network hub 106 may adjust the account balance 119 of the subscriber account 113 associated with the operator of the super network 200. For example, the network hub 106 may add an amount of funds equal to the amount specified in the settlement request, plus any additional transaction fees, to the account balance 119 of the subscriber account 113 of the super network 200.

[0038] If the process proceeds to block 336, the network hub 106 may release the hold on the account balance 119 of the payee subscriber account 113. The process may then terminate.

[0039] Referring now to Figure 4, a flowchart is shown illustrating one example of the operation of a portion of network hub 106. The flowchart of Figure 4 is merely one example of many different types of functional configurations that can be employed to implement the operation of the illustrated portion of network hub 106. Alternatively, the flowchart of Figure 4 can be viewed as illustrating example elements of a method implemented within RTP network 100 or super-network 200.

[0040] Starting at block 403, a network hub 106 may receive a settlement request from a global transaction router 206 of a supernetwork instance 203 connected to the network hub 106. For example, if a first network hub 106a forwards a settlement request to the global transaction router 206a using the process described in Figure 3, a recipient network hub 106 (e.g., network hub 106h) may receive a corresponding settlement request from a global transaction router 206b of the supernetwork instance 203b.

[0041] Next, in block 406, the network hub 106 may determine whether the account balance 119 of the subscriber account 113 associated with the operator of the super network 200 has sufficient funds to fulfill the transaction. If there are not enough funds (e.g., because the payment request is larger than the current account balance 119 of the super network 200 within the RTP network 100), the process may proceed to block 409. However, if there are sufficient funds to fulfill the payment request, the process may proceed to block 411.

[0042] If the process proceeds to block 409, the network hub 106 may generate a payment denial message and send the payment denial message back to the global transaction router 206 of the super network instance 203 to which the network hub 106 is connected. The payment denial message may include the subscriber identifier 116 from which the payment was sent and, in some cases, the network identifier 109 from which the payment was sent. In some cases, the payment denial message may include the reason the payment was denied, while in other cases the reason for the denial of the payment request may be omitted.

[0043] However, if the process proceeds to block 413, the network hub 106 may adjust the account balance 119 of the subscriber account 113 associated with the operator of the super network 200. For example, the network hub 106 may deduct an amount of funds equal to the amount specified in the settlement request. The network hub 106 may also deduct any additional transaction fees from the account balance 119 of the subscriber account 113 of the operator of the super network 200 to compensate the RTP network 100 operator for the cost of processing the transaction.

[0044] Next, in block 413, the network hub 106 may adjust the account balance 119 of the recipient's subscriber account 113. Thus, the network hub 106 may search for a subscriber account 113 that matches the subscriber identifier 116 specified in the payment request. The network hub 106 may then add an amount of funds equal to the amount specified in the payment request to the account balance 119 of the matching subscriber account 113.

[0045] Thereafter, in block 416, the network hub 106 may generate and send a payment acceptance message back to the global transaction router 206 of the super network instance 203 to which the network hub 106 is connected. The payment acceptance message may include information such as a confirmation code or number, confirmation of the amount to be deposited into the recipient's account balance 119, a timestamp indicating when the recipient received the funds, the subscriber identifier 116 from which the payment was sent, and possibly the network identifier 109 from which the payment was sent, as well as other information. The process may then terminate thereafter.

[0046] Referring now to Figure 5, a flowchart illustrating one example of the operation of portions of the global trading router 206 is shown. The flowchart of Figure 5 is merely one example of many different types of functional configurations that can be employed to implement the operation of the described portions of the global trading router 206. Alternatively, the flowchart of Figure 5 can be viewed as illustrating one example of elements of a method implemented within the super network 200.

[0047] Beginning at block 501, the global transaction router 206 may receive a settlement request from an originating network hub 106. For example, the settlement request may have been received as part of the process performed by the originating network hub 106 in block 323. The settlement request may include information such as the network identifier 109 and subscriber identifier 116 of the settling subscriber, the recipient subscriber identifier 116, the subscriber's network identifier 109 (if known), the settlement amount, and possibly other information depending on the particular implementation of the present disclosure.

[0048] Moving to block 503, the global transaction router 206 may determine whether the recipient of the settlement request is a subscriber of the RTP network 100 having a network hub 106 connected to the supernetwork instance 203 of the supernetwork 200. This network hub 106 will be the destination network hub 106 for the settlement request. For example, the global transaction router 206 may search the subscriber status cache 209 to identify a subscriber record 216 having a matching subscriber identifier 116. If the subscriber record 216 exists, the process may proceed to block 506. If the subscriber record 216 does not exist, the process may instead skip to block 516.

[0049] Next, in block 506 , the global trading router 206 may obtain the network identifier 109 of the destination network hub 106 from the subscriber record 216 identified in block 503 .

[0050] Next, in block 507, the global transaction router 206 may identify the super network instance 203 to which the destination network hub 106 associated with the destination network identifier 109 obtained in block 506 is connected. For example, the global transaction router 206 may search the RTP registration data 217 in the subscriber registry 211 to identify the super network instance 203 associated with the network identifier 109. However, in some implementations, the global transaction router 206 may cache a list of network hubs 106 to which the global transaction router 206 is connected, in which case the global transaction router 206 may query that cache instead of the subscriber cache registry 211.

[0051] Proceeding to block 508, the global transaction router 206 may determine whether the destination network hub 106 of the settlement request is connected to the supernetwork instance 203 hosting the global transaction router 206 (e.g., supernetwork instance 203a) or to a second supernetwork instance 203 (e.g., supernetwork instance 203b). This may be done by determining whether the supernetwork instance 203 identified in block 507 is the same supernetwork instance 203 hosting the global transaction router 206. If the destination network hub 106 is connected to the same supernetwork instance 203 hosting the global transaction router 206, the process may proceed to block 510. However, if the destination network hub 106 is connected to a second supernetwork instance 203, the process may proceed to block 511.

[0052] If the process proceeds to block 510, the global transaction router 206 may send a settlement request to a destination network hub 106 connected to the super network instance 203 hosting the global transaction router 206. The global transaction router 206 may then wait to receive a response from the destination network hub 106 regarding the settlement status.

[0053] However, if the process proceeds to block 511, the global trade router 206 may send a settlement request to a global trade router 206 hosted by the super network instance 203 identified in block 509. The global trade router 206 may then wait to receive a response from that second global trade router 206 regarding the settlement status.

[0054] Thereafter, in block 513, the global transaction router 206 may receive a settlement response indicating the status of the settlement request and return or forward it to the originating network hub 106. For example, the global transaction router 206 may search the subscriber status cache 209 to identify a subscriber record 216 having a matching subscriber identifier 116. The global transaction router 206 may then determine the network identifier 109 of the message destination and determine that the network identifier 109 is for a network hub 106 (e.g., the originating network hub 106) connected to the supernetwork instance 203 hosting the global transaction router 206. For example, the global transaction router 206 may query the RTP registration data in the subscriber cache registry 211 to determine that the destination network hub 106 is connected to the global transaction router 206. However, in some implementations, the global trading router 206 may cache a list of the network hubs 106 to which the global trading router 206 is connected, in which case the global trading router 206 can query that cache instead of the subscriber cache registry 211.

[0055] The global transaction router 206 may also cache or temporarily store the settlement response for use in block 516 .

[0056] Next, in block 516, the global transaction router 206 stores or records the transaction in the transaction ledger 213. For example, if the payment response received in block 513 was a payment acceptance message, the global transaction router 206 may record a transaction record 219 in the transaction ledger 213 that includes information such as a confirmation code or number, confirmation of the amount to be deposited into the recipient's account balance 119, a timestamp indicating when the recipient received the funds, the subscriber identifier 116 from which the payment was sent, and optionally the network identifier 109 from which the payment was sent, as well as other information. Similarly, if the payment response was a payment rejection message, the global transaction router 206 may record a transaction record 219 in the transaction ledger 213 that includes the subscriber identifier 116 from which the payment was sent, and optionally the network identifier 109 from which the payment was sent. In some cases, the payment rejection message may include a reason why the payment was rejected, in which case the reason for the rejection may also be included in the transaction record 219. The process may then terminate.

[0057] If the process proceeds to block 519, the global transaction router 206 may generate and send an error message back to the originating network hub 106 indicating that the settlement request could not be fulfilled. In some implementations, the error message may include an indicator of the problem (e.g., the destination is not a member of a supported RTP network 100, the super network does not have sufficient funds at the destination, etc.). Once the error message is sent, the process may end.

[0058] Referring now to Figure 6, a flowchart illustrating one example of the operation of portions of the global trading router 206 is shown. The flowchart of Figure 6 is merely one example of many different types of functional configurations that can be employed to implement the operation of the described portions of the global trading router 206. Alternatively, the flowchart of Figure 6 can be viewed as illustrating one example of elements of a method implemented within the super network 200.

[0059] Starting at block 603, a global trade router 206 (e.g., global trade router 206b) of a second supernetwork instance (e.g., supernetwork instance 203b) may receive a settlement request from a first global trade router 206 (e.g., global trade router 206a) hosted or executed by a first supernetwork instance (e.g., supernetwork instance 203a). The settlement request may be received as a result of the first global trade router 206 determining that the second global trade router 206 has a connection to the network hub 106 of the settlement recipient. An example of this process is described above and illustrated by FIG. 5.

[0060] Next, in block 606, the global transaction router 206 identifies the destination network hub 106. For example, the global transaction router 206 can analyze the payment request to determine the recipient's subscriber identifier 116. The global transaction router 206 can then query a subscriber status cache to search for a subscriber record 216 with a matching subscriber identifier 116. The global transaction router 206 can then retrieve the network identifier 109 from the subscriber record 216. The global transaction router 206 can then query the RTP registration data in the subscriber cache registry 211 to determine that the destination network hub 106 is connected to the global transaction router 206. However, in some cases, the global transaction router 206 may cache a list of network hubs 106 to which the global transaction router 206 is connected, in which case the global transaction router 206 can query that cache instead of the subscriber cache registry 211.

[0061] Next, in block 609 , the global transaction router 206 may then forward or otherwise transmit the settlement request received in block 603 to the network hub 106 identified in block 606 .

[0062] Moving to block 613, the global transaction router 206 may receive a settlement response from the destination network hub 106 to which the settlement request was forwarded in block 609. The settlement response may be a settlement acceptance, a settlement rejection, or other settlement status message, as previously described.

[0063] Thereafter, in block 616, the global transaction router 206 may return the settlement response received in block 613 to the originating super network instance 203 from which the settlement request was received in block 603. For example, the global transaction router 206 may search the subscriber status cache 209 to identify a subscriber record 216 with a matching subscriber identifier 116 that specifies the origin of the settlement and, therefore, the destination of the settlement response. The global transaction router 206 may obtain the network identifier 109 from the identified subscriber record 216. However, this may be skipped if the settlement response included a network identifier 109 that identifies the destination of the settlement response. The global transaction router 206 may then search the RTP registration data 217 in the subscriber registry 211 to identify the super network instance 203 associated with that network identifier 109 and forward the settlement response to the identified super network instance 203. The process may then terminate.

[0064] The aforementioned software components are stored in the memory of each computing device and are executable by the processor of the respective computing device. In this context, the term "executable" refers to a program file in a format ultimately executable by a processor. Examples of executable programs can be machine code, which can be loaded into a random-access portion of memory and executed by the processor; source code, which can be expressed in any suitable format, such as object code, which can be loaded into a random-access portion of memory and executed by the processor; or a compiled program that can be interpreted by another executable program to generate instructions in a random-access portion of memory and converted into source code that can be executed by the processor. Executable programs can be stored in any portion or component of memory, including random-access memory (RAM), read-only memory (ROM), hard drives, solid-state drives, universal serial bus (USB) flash drives, memory cards, optical disks such as compact discs (CDs) or digital versatile discs (DVDs), floppy disks, magnetic tape, or other memory components.

[0065] Memory includes both volatile and nonvolatile memory and data storage components. Volatile components are components that do not retain data values ​​when power is lost. Nonvolatile components are components that retain data when power is lost. Thus, memory may include random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed through a memory card reader, floppy disks accessed through an associated floppy disk drive, optical disks accessed through an optical disk drive, magnetic tape accessed through an appropriate tape drive, or other memory components, or a combination of any two or more of these memory components. Furthermore, RAM may include static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM), and other such devices. ROM may include programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other similar memory devices.

[0066] The applications and systems described herein may be embodied in software or code executed by the general-purpose hardware described above, but may alternatively be embodied in dedicated hardware or a combination of software / general-purpose hardware and dedicated hardware. If embodied in dedicated hardware, each may be implemented as a circuit or state machine employing any one or combination of several technologies. These technologies may include, but are not limited to, discrete logic circuits having logic gates for implementing various logical functions upon the application of one or more data signals, application-specific integrated circuits (ASICs) having appropriate logic gates, field-programmable gate arrays (FPGAs), or other components. Such technologies are generally well known to those skilled in the art and, therefore, will not be described in detail herein.

[0067] The flowchart illustrates the functionality and operation of some implementations of various embodiments of the present disclosure. When embodied in software, each block may represent a module, segment, or portion of code containing program instructions for implementing the specified logical function(s). The program instructions may be embodied in the form of source code, which includes human-readable statements written in a programming language, or machine code, which includes numerical instructions recognizable by a suitable execution system, such as a processor of a computer system. Machine code can be transformed from source code through various processes. For example, machine code can be generated from source code using a compiler prior to executing the corresponding application. As another example, machine code can be generated from source code upon execution by an interpreter. Other approaches can also be used. When embodied in hardware, each block may represent a circuit or several interconnected circuits for implementing one or more specified logical functions.

[0068] Although the flowcharts show a particular order of execution, it is understood that the order of execution may differ from that depicted. For example, the order of execution of two or more blocks may be scrambled relative to the order shown. Also, two or more blocks shown in succession may be executed in parallel or with partial parallelism. Furthermore, in some embodiments, one or more of the blocks shown in the flowcharts may be skipped or omitted. Furthermore, any number of counters, state variables, warning semaphores, or messages may be added to the logic flows described herein for purposes such as utility, accounting, enhanced performance measurement, or to provide troubleshooting assistance. All such variations are understood to be within the scope of this disclosure.

[0069] Additionally, the logic or applications described herein, including software or code, can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system, such as a processor of a computer system or other system. In this sense, logic can include statements, including instructions and declarations, that can be fetched from a computer-readable medium and executed by an instruction execution system. In the context of this disclosure, a "computer-readable medium" can be any medium that can contain, store, or maintain the logic or applications described herein for use by or in connection with an instruction execution system. Also, a collection of distributed computer-readable media located across multiple computing devices (e.g., a storage area network or a distributed or clustered file system or database) can collectively be considered a single non-transitory computer-readable medium.

[0070] A computer-readable medium can include any one of many physical media, such as magnetic, optical, or semiconductor media. More specific examples of suitable computer-readable media include, but are not limited to, magnetic tape, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical disks. Additionally, a computer-readable medium can be random access memory (RAM), including static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). Furthermore, a computer-readable medium can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other types of memory devices.

[0071] Furthermore, any logic or application described herein may be implemented and structured in a variety of ways. For example, one or more applications described herein may be implemented as modules or components of a single application. Furthermore, one or more applications described herein may execute on shared or separate computing devices, or a combination thereof. For example, multiple applications described herein may execute on the same computing device or on multiple computing devices within the same computing environment.

[0072] Unless otherwise expressly stated, disjunctive language, such as the phrase "at least one of X, Y, or Z," is otherwise understood in the context where it is generally used to express that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X; Y; Z; X or Y; X or Z; Y or Z; X, Y, or Z, etc.). Thus, such disjunctive language is generally not intended to, and should not, imply that a particular embodiment requires at least one of X, at least one of Y, or at least one of Z, and each is present.

[0073] It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations, described so that the principles of the present disclosure may be clearly understood. Many variations and modifications can be made to the above-described embodiments without substantially departing from the spirit and principles of the present disclosure. All such modifications and modifications are intended to be included herein within the scope of the present disclosure and protected by the following claims. Examples of some of these modifications are described in the following sections.

[0074] Claim 1 - A system comprising: a computing device including a processor and a memory; and a first global trading router hosted by a first supernetwork instance, the global trading router comprising machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least: receive a settlement request from a source network hub connected to the first supernetwork instance and linked to a first settlement network, the first settlement request specifying an identifier of a recipient institution and an amount of the settlement request; querying a subscriber status cache to identify a destination network hub linked to a second settlement network associated with the recipient institution; querying a subscriber registry to identify a second supernetwork instance connected to the destination network hub; and forwarding the settlement request to a second global trading router hosted by the second supernetwork instance connected to the destination network hub.

[0075] Clause 2 - The system of clause 1, wherein the first global trading router further causes the computing device to at least receive a second settlement request from the second global trading router, query a subscriber registry to determine that the second settlement request is destined for a second destination network hub connected to the first supernetwork instance, and forward the second settlement request to the second destination hub.

[0076] Clause 3 - The system of clause 2, wherein the first global transaction router further causes the computing device to at least receive a settlement response from a second destination network hub, query a subscriber registry to determine that the settlement response is destined for a network hub associated with a second supernetwork instance that hosts the second global transaction router, and forward the settlement response to the second global transaction router.

[0077] Clause 4 - The system described in clauses 1 to 3, wherein the first global trading router further causes the computing device to at least receive a settlement response from the second global trading router, query a subscriber status cache to identify the originating network hub as a recipient of the settlement response, query a subscriber registry or cache to determine that the originating network hub is connected to the first super network instance, and forward the settlement response to the originating network hub.

[0078] Clause 5 - The system described in clause 4, wherein the first global transaction router further causes a computing device to at least extract transaction information from the settlement response and record a transaction record including the transaction information in a transaction ledger.

[0079] Clause 6 - The system described in clause 4 or clause 5, wherein the payment response is a payment acceptance message.

[0080] Clause 7 - The system described in clause 4 or clause 5, wherein the payment response is a payment rejection message.

[0081] Clause 8 - A method comprising: receiving, by a first global transaction router hosted by a first supernetwork instance, a settlement request from an originating network hub connected to the first supernetwork instance and linked to a first settlement network, the first settlement request specifying an identifier of a recipient institution and an amount of the settlement request; querying, by the first global transaction router hosted by the first supernetwork instance, a subscriber status cache to identify a destination network hub linked to a second settlement network associated with the recipient institution; querying, by the first global transaction router hosted by the first supernetwork instance, a subscriber registry to identify a second supernetwork instance connected to the destination network hub; and forwarding, by the first global transaction router hosted by the first supernetwork instance, the settlement request to a second global transaction router hosted by a second supernetwork instance connected to the destination network hub.

[0082] Clause 9 - The method of clause 8, further comprising: receiving, by a first global trading router hosted by the first supernetwork instance, a second settlement request from a second global trading router; querying, by the first global trading router hosted by the first supernetwork instance, a subscriber registry to determine that the second settlement request is destined for a second destination network hub connected to the first supernetwork instance; and forwarding, by the first global trading router hosted by the first supernetwork instance, the second settlement request to the second destination hub.

[0083] Clause 10 - The method of clause 9, further comprising: receiving, by a first global transaction router hosted by the first supernetwork instance, a settlement response from a second destination network hub; querying, by the first global transaction router hosted by the first supernetwork instance, a subscriber registry to determine that the settlement response is destined for a network hub associated with the second supernetwork instance hosting the second global transaction router; and forwarding, by the first global transaction router hosted by the first supernetwork instance, the settlement response to the second global transaction router.

[0084] Clause 11 - The method of clauses 8 to 10, further comprising: receiving, by a first global transaction router hosted by the first supernetwork instance, a settlement response from the second global transaction router; querying, by the first global transaction router hosted by the first supernetwork instance, a subscriber status cache to identify the originating network hub as a recipient of the settlement response; querying, by the first global transaction router hosted by the first supernetwork instance, a subscriber registry or cache to determine that the originating network hub is connected to the first supernetwork instance; and forwarding, by the first global transaction router hosted by the first supernetwork instance, the settlement response to the originating network hub.

[0085] Clause 12 - The method of clause 11, further comprising: extracting, by a first global transaction router hosted by the first super network instance, transaction information from the settlement response; and recording, by the first global transaction router hosted by the first super network instance, a transaction record in a transaction ledger that includes the transaction information.

[0086] Clause 13 - The method of clause 11 or clause 12, wherein the payment response is a payment acceptance message.

[0087] Clause 14 - The method of clause 11 or clause 12, wherein the payment response is a payment rejection message.

[0088] Item 15 - A non-transitory computer-readable medium including a first global transaction router hosted by a first supernetwork instance, the global transaction router including machine-readable instructions that, when executed by a processor of a computing device, cause the computing device to at least: receive a settlement request from a source network hub connected to the first supernetwork instance and linked to a first settlement network, the first settlement request specifying an identifier of a recipient institution and an amount of the settlement request; query a subscriber status cache to identify a destination network hub linked to a second settlement network associated with the recipient institution; query a subscriber registry to identify a second supernetwork instance connected to the destination network hub; and forward the settlement request to a second global transaction router hosted by the second supernetwork instance connected to the destination network hub.

[0089] Clause 16 - The non-transitory computer-readable medium of clause 15, wherein the first global trading router further causes the computing device to at least receive a second settlement request from the second global trading router, query a subscriber registry to determine that the second settlement request is destined for a second destination network hub connected to the first supernetwork instance, and forward the second settlement request to the second destination hub.

[0090] Clause 17 - The non-transitory computer-readable medium of clause 16, wherein the first global trading router further causes the computing device to at least receive a settlement response from a second destination network hub, query a subscriber registry to determine that the settlement response is destined for a network hub associated with a second supernetwork instance that hosts the second global trading router, and forward the settlement response to the second global trading router.

[0091] Clause 18 - A non-transitory computer-readable medium as described in clauses 15 to 17, wherein the first global trading router further causes the computing device to at least receive a settlement response from the second global trading router, query a subscriber status cache to identify the originating network hub as a recipient of the settlement response, query a subscriber registry or cache to determine that the originating network hub is connected to the first super network instance, and forward the settlement response to the originating network hub.

[0092] Item 19 - The non-transitory computer-readable medium of item 18, wherein the first global transaction router further causes a computing device to at least extract transaction information from the settlement response and record a transaction record including the transaction information in a transaction ledger.

[0093] Item 20 - The non-transitory computer-readable medium of item 18 or 19, wherein the payment response is a payment rejection message or a payment acceptance message.

Claims

1. a computing device including a processor and a memory; a first global trading router hosted by a first supernetwork instance, the global trading router including machine-readable instructions stored in the memory, the machine-readable instructions, when executed by the processor, causing the computing device to perform at least: receiving a settlement request from an originating network hub connected to the first super-network instance and linked to a first settlement network, the first settlement request specifying an identifier of a recipient institution and an amount of the settlement request; querying a subscriber status cache to identify a destination network hub linked to a second payment network associated with the recipient institution; Querying a subscriber registry to identify a second supernetwork instance connected to the destination network hub; and forwarding the settlement request to a second global trading router hosted by a second supernetwork instance connected to the destination network hub.

2. The first global trading router further configures the computing device to include at least: receiving a second settlement request from the second global transaction router; querying the subscriber registry to determine that the second settlement request is destined for a second destination network hub connected to the first supernetwork instance; and forwarding the second settlement request to the second destination hub.

3. The first global trading router further configures the computing device to include at least: receiving a settlement response from the second destination network hub; querying the subscriber registry to determine that the settlement response is destined for a network hub associated with the second supernetwork instance that hosts the second global transaction router; and forwarding the settlement response to the second global transaction router.

4. The first global trading router further configures the computing device to include at least: receiving a settlement response from the second global transaction router; querying a subscriber status cache to identify the originating network hub as a recipient of the settlement response; querying a subscriber registry or cache to determine that the source network hub is connected to the first supernetwork instance; and forwarding the settlement response to the originating network hub.

5. The first global trading router further configures the computing device to include at least: extracting transaction information from the payment response; and recording a transaction record including said transaction information in a transaction ledger.

6. The system of claim 4 or 5, wherein the payment response is a payment acceptance message.

7. The system of claim 4 or 5, wherein the payment response is a payment rejection message.

8. receiving, by a first global transaction router hosted by a first supernetwork instance, a settlement request from an originating network hub connected to the first supernetwork instance and linked to a first settlement network, the first settlement request specifying an identifier of a recipient institution and an amount of the settlement request; querying a subscriber status cache by the first global transaction router hosted by the first supernetwork instance to identify a destination network hub linked to a second payment network associated with the recipient institution; querying a subscriber registry to identify a second supernetwork instance connected to the destination network hub by the first global trading router hosted by the first supernetwork instance; and forwarding, by the first global trading router hosted by the first supernetwork instance, the settlement request to a second global trading router hosted by a second supernetwork instance connected to the destination network hub.

9. receiving, by the first global trading router hosted by the first supernetwork instance, a second settlement request from the second global trading router; querying the subscriber registry by the first global transaction router hosted by the first supernetwork instance to determine that the second settlement request is destined for a second destination network hub connected to the first supernetwork instance; 10. The method of claim 8, further comprising forwarding the second settlement request to the second destination hub by the first global transaction router hosted by the first supernetwork instance.

10. receiving, by the first global transaction router hosted by the first supernetwork instance, a settlement response from the second destination network hub; querying the subscriber registry by the first global transaction router hosted by the first supernetwork instance to determine that the settlement response is destined for a network hub associated with the second supernetwork instance hosting the second global transaction router; 10. The method of claim 9, further comprising forwarding, by the first global transaction router hosted by the first supernetwork instance, the settlement response to the second global transaction router.

11. receiving, by the first global transaction router hosted by the first supernetwork instance, a settlement response from the second global transaction router; querying, by the first global transaction router hosted by the first supernetwork instance, a subscriber status cache to identify the originating network hub as a recipient of the settlement response; querying, by the first global trading router hosted by the first supernetwork instance, a subscriber registry or cache to determine that the source network hub is connected to the first supernetwork instance; and forwarding the settlement response to the originating network hub by the first global transaction router hosted by the first supernetwork instance.

12. extracting, by the first global transaction router hosted by the first supernetwork instance, transaction information from the settlement response; 12. The method of claim 11, further comprising recording, by the first global trade router hosted by the first supernetwork instance, a trade record in a trade ledger that includes the trade information.

13. 13. The method of claim 11 or 12, wherein the payment response is a payment acceptance message.

14. 13. The method of claim 11 or 12, wherein the payment response is a payment denial message.

15. 1. A non-transitory computer-readable medium comprising: a first global trading router hosted by a first supernetwork instance, said global trading router comprising machine-readable instructions that, when executed by a processor of a computing device, cause said computing device to perform at least: receiving a settlement request from an originating network hub connected to the first super-network instance and linked to a first settlement network, the first settlement request specifying an identifier of a recipient institution and an amount of the settlement request; querying a subscriber status cache to identify a destination network hub linked to a second payment network associated with the recipient institution; Querying a subscriber registry to identify a second supernetwork instance connected to the destination network hub; and forwarding the settlement request to a second global trading router hosted by a second supernetwork instance connected to the destination network hub.

16. The first global trading router further configures the computing device to include at least: receiving a second settlement request from the second global transaction router; querying the subscriber registry to determine that the second settlement request is destined for a second destination network hub connected to the first supernetwork instance; and forwarding the second settlement request to the second destination hub.

17. The first global trading router further configures the computing device to include at least: receiving a settlement response from the second destination network hub; querying the subscriber registry to determine that the settlement response is destined for a network hub associated with the second supernetwork instance that hosts the second global transaction router; and forwarding the settlement response to the second global transaction router.

18. The first global trading router further configures the computing device to include at least: receiving a settlement response from the second global transaction router; querying a subscriber status cache to identify the originating network hub as a recipient of the settlement response; querying a subscriber registry or cache to determine that the source network hub is connected to the first supernetwork instance; and forwarding the settlement response to the source network hub.

19. The first global trading router further configures the computing device to include at least: extracting transaction information from the payment response; and recording a transaction record including the transaction information in a transaction ledger.

20. 20. The non-transitory computer-readable medium of claim 18 or 19, wherein the payment response is a payment rejection message or a payment acceptance message.

Images