Payment Threading and How it Accelerates Throughput in Payment Systems
By Samantha Cook (Chief Scientist)
Payment system infrastructure can only process so many transactions per second. If the number of transactions submitted is larger than that limit in any time period, delays will result due to the system’s inability to process transactions immediately. Moreover, as DLT-based settlement systems allow for atomic (i.e., instantaneous and simultaneous) settlement, the potential for bottlenecks in processing transactions is expected to increase.
For example, The Mexican interbank electronic payment system, SPEI (Sistema de Pagos Electrónicos Interbancarios), processes 15 different payment types in a single system. In 2021, SPEI processed nearly two billion payments, and in the four years leading up to 2021, the volume of payments processed by SPEI increased by an average of 43 per year. The SIC (Swiss Interbank Clearing System) in Switzerland processed nearly one billion transactions in 2021, and the HVPS (High-Value Payment System) in China processed nearly 500,000 (1). Each of these three systems processed more payments in 2021 than Fedwire and Target2 combined. As the global economy continues to grow and atomic settlement gains importance, the payment volume in these and other systems could exceed their operational capacity.
Operating several identical systems in parallel could reduce the payment volume in each individual system. However, “splitting up” a single system into multiple systems introduces liquidity risk, as fewer chances for liquidity recycling means participants will likely need to use more liquidity to settle transactions in a timely manner. To mitigate the risks of payment delays due to the continually growing volume of transactions and the increasing markets using atomic settlement, could Payment Threading offer a solution, mitigating the need for a complete system overhaul without substantially increasing liquidity requirements?
What is Payment Threading?
FNA’s patented Payment Threading solution enables multiple replicas or threads of the payment infrastructure to operate in parallel or sequentially to execute payment requests simultaneously, leading to quicker, more streamlined payment flows and smoother handling of a high volume of transactions processed in a given amount of time, ultimately overcoming delays.
The solution works by assigning participants in the system to threads. Each participant must operate in at least one thread and may operate in many or all threads. Those participants who transact with all or most of the other participants in the system will likely need to operate in all threads.
To efficiently assign each participant to a thread, we use network community detection. This method simply creates a network from a set of transactions, firstly by adding each participant (a sender and receiver of each transaction) to the network as a node. Then, whenever there is at least one transaction from one given participant to another, a link is added from the sending participant to the receiving participant. Since transactions have a sender and a receiver, the links are directed and, therefore, may be present in both directions between a pair of nodes, as any one participant can, in theory, both send to and receive from any other participant. Links may also be assigned weights corresponding to either value of the volume of the transaction made between pairs of participants.
Network-based community detection attempts to group nodes into communities such that there are many more links within communities than between them. There are many computational algorithms available to implement the classification of communities.
Community detection algorithms can be constrained so that the number of communities is equal to the desired number of threads. Given a classification of participants into communities, each community represents the set of participants in a single thread. Some participants will likely need to be added to additional threads to ensure that all counterparty relationships (i.e., each pair of participants that transact with each other) are present in at least one thread.
It is possible that participants will occasionally need to be reassigned to threads (for example, annually) to account for changes in the system, such as the addition of new participants and evolving counterparty relationships, which may change the dynamics of the network and communities within it.
Assigning transactions to threads
To assign a transaction to a thread, we must find all the threads containing both the sending and receiving institutions of the transaction. If there is only one such thread, the payment will be assigned to and settled in that thread. If both institutions are present in multiple threads, we can balance the load among threads by choosing the thread that has processed the least number of payments in the past few minutes or seconds. Alternatively, the payment could be settled in the thread where the sending institution has the most available liquidity.
Liquidity Management
Participants who are present in more than one thread will need to have separate liquidity allocations to each thread. At the start of the day, liquidity may be allocated to each thread based on the number of counterparties a participant has in each thread or the difference between the average value sent and received with the counterparties in each thread. As the day goes on, participants may find themselves short on liquidity in some threads and long in others and may have to reallocate liquidity among threads based on current balances and projects on liquidity required to settle the day’s remaining payments. Intelligent liquidity forecasting will allow participants to balance liquidity across threads based on projected liquidity needs.
Conclusion
As payment systems continue to grow alongside the global economy and instant and simultaneous settlement extend, demands on payment infrastructure will also continue to grow. Payment threading provides a simple solution to an increasingly important problem, with the major benefit of the solution being that it does not require a new system or architecture design, only a replication of the existing architecture.
New participants entering the payment system can easily be incorporated without the need for major changes to the system architecture. Moreover, the number of threads may be increased as necessary as the number of participants and/or payments in the system increases with minimal changes to the existing system.
For more information on FNA’s patented Payment Threading Solution, get in touch with FNA at info@fna.fi.
Footnotes:
(1) BIS Stats: T8: Volume of transactions processed by selected payment systems
