(AGENPARL) – Wed 15 October 2025 Mercati, infrastrutture, sistemi di pagamento
(Markets, Infrastructures, Payment Systems)
A solution for cross-border and cross-currency interoperability
of instant payment systems
Number
October 2025
by Domenico Di Giulio, Vitangelo Lasorella, Pietro Tiberi
Mercati, infrastrutture, sistemi di pagamento
(Markets, Infrastructures, Payment Systems)
A solution for cross-border and cross-currency interoperability
of instant payment systems
by Domenico Di Giulio, Vitangelo Lasorella, Pietro Tiberi
Number 69 – October 2025
The papers published in the ‘Markets, Infrastructures, Payment Systems’ series provide
information and analysis on aspects regarding the institutional duties of the Bank of
Italy in relation to the monitoring of financial markets and payment systems and the
development and management of the corresponding infrastructures in order to foster
a better understanding of these issues and stimulate discussion among institutions,
economic actors and citizens.
The views expressed in the papers are those of the authors and do not necessarily reflect
those of the Bank of Italy.
The series is available online at http://www.bancaditalia.it.
Printed copies can be requested from the Paolo Baffi Library:
Editorial Board: Stefano Siviero, Paolo Del Giovane, Massimo Doria,
Giuseppe Zingrillo, Paolo Libri, Guerino Ardizzi, Paolo Bramini, Francesco Columba,
Luca Filidi, Tiziana Pietraforte, Alfonso Puorro, Antonio Sparacino.
Secretariat: Yi Teresa Wu.
ISSN 2724-6418 (online)
ISSN 2724-640X (print)
Banca d’Italia
Via Nazionale, 91 – 00184 Rome – Italy
Designed and printing by the Printing and Publishing Division of the Bank of Italy
A SOLUTION FOR CROSS-BORDER AND
CROSS-CURRENCY INTEROPERABILITY
OF INSTANT PAYMENT SYSTEMS
by Domenico Di Giulio,* Vitangelo Lasorella,** Pietro Tiberi***
Abstract
Instant Payment Systems (IPSs) enable real-time settlement of transactions, providing immediate
confirmation of payment status to both parties. However, these systems are predominantly tailored
to domestic use and typically operate within specific jurisdictions. Consequently, their capacity to
support cross-border and cross-currency transactions is limited.This paper proposes a novel approach
for interconnecting IPSs to facilitate cross-border and cross-currency payments, effectively extending
these functionalities as an overlay to existing domestic systems. The proposed model introduces a
standardized protocol that enables the synchronous processing of instant payments across different
IPSs, thereby preserving the immediacy and user experience that are typical of domestic instant
payments, even in international contexts.
Crucially, the proposed interlinking model avoids relying on a centralized hub, which would require
designating a central institution to build and manage shared infrastructure. Instead, we advocate using
a decentralized approach which, through the adoption of a standardized protocol and the development
of an adapter—or gateway—capable of translating and routing messages, allows different IPSs to
interoperate directly. This decentralized approach leverages existing bilateral connections between
IPSs, repurposing them to form a network of autonomous yet interoperable systems.
Keywords: Instant payments, cross-border payments.
Sintesi
I sistemi di pagamento istantaneo (Instant Payment Systems, IPS) consentono il regolamento in
tempo reale delle transazioni, fornendo a entrambe le parti una conferma immediata dello stato del
pagamento. Tuttavia, tali sistemi sono prevalentemente progettati per un utilizzo a livello nazionale
e operano generalmente all’interno di specifiche giurisdizioni. Di conseguenza, la possibilità di
un loro utilizzo nelle transazioni transfrontaliere e cross-currency risulta limitata. Questo lavoro
propone un approccio innovativo per interconnettere gli IPS, con l’obiettivo di facilitare i pagamenti
transfrontalieri e cross-currency, estendendo tali funzionalità tramite un’estensione delle funzionalità
dei sistemi domestici esistenti. Il modello proposto introduce un protocollo standardizzato che
consente l’elaborazione sincrona dei pagamenti istantanei in transito tra IPS diversi, preservando
così l’immediatezza e l’esperienza utente tipiche dei pagamenti istantanei domestici, anche in
contesti internazionali.
Digital Euro Unit, Banca d’Italia.
IT Development Directorate, Banca d’Italia.
IT Operations Directorate, Banca d’Italia.
Elemento centrale del modello di interconnessione proposto è l’eliminazione della necessità di
un hub centralizzato, che implicherebbe la designazione di un’istituzione centrale che realizzi e
gestisca l’infrastruttura comune. Al contrario, si promuove un approccio decentralizzato che, tramite
l’adozione di un protocollo standardizzato e lo sviluppo di un adattatore – o gateway – capace
di tradurre e instradare i messaggi, consenta a IPS diversi di interoperare direttamente. Questo
approccio sfrutta le connessioni bilaterali già esistenti tra gli IPS, riconvertendole in una rete di
sistemi autonomi ma interoperabili.
CONTENTS
1. Introduction
2. The cross-border payments today
3. Architectures and interoperability
3.1. Which interoperability model for cross-border instant payments?
4. The proposal: An “IPS network model” for interlinking local Instant Payment Systems
4.1. The proposal: service interoperability and networks interoperability
4.2. The network layer: messages
4.3. The service layer: payments and related services
5. IPS interlinking protocol
5.1. The service interoperability protocol
5.2. A more effective network layer: the network interoperability protocol
6. A further step: automatic foreign exchange
7. Conclusions
References
Introduction
Instant payments (IP), also known as fast payments, are credit transfers that reach the recipient’s
bank account within seconds. This process occurs in real-time, at any hour of the day and on any day
of the year, meaning that funds are made immediately available to the receiver. In contrast, regular
online bank transfers typically take at least one business day to reach the recipient’s account.
Instant payment systems (IPS) enable fast, secure, and convenient transfers of funds, which
enhances efficiency in various financial transactions, including person-to-person transfers, bill
payments, online purchases, and B2B transactions. Compared to traditional funds transfer methods,
instant payment systems provide immediate proof that the payment is final, facilitating business
cases that previously could only be handled with cash.
However, IPSs are designed to meet domestic requirements and operate in domestic areas. The
cross-border and cross-currency functionalities are impeded by the fact that these infrastructures
are provided by central banks and other institutions operating within specific jurisdictions.1
Cross-border instant payments, while offering significant advantages in terms of speed, convenience, and efficiency, also present several challenges. Some of the key challenges associated
with cross-border instant payments include:
• Regulatory Hurdles: Regulatory frameworks vary significantly across jurisdictions, which can
complicate cross-border transactions. Compliance with anti-money laundering (AML) and knowyour-customer (KYC) regulations, as well as differing legal requirements, can create barriers to
seamless cross-border instant payments.This becomes even more challenging when it must fit
within the time frame of a synchronous instant payment.
• Currency Conversion Costs: Instant cross-border payments often involve currency conversion
when transferring funds across borders. Currency conversion costs, including exchange rate fees
and spreads, can be relatively high.
• Liquidity Management: Ensuring sufficient liquidity across different payment systems and
currencies is essential for enabling cross-border instant payments. However, managing liquidity
effectively in real-time across multiple jurisdictions can be complex and may require coordination
among financial institutions and central banks. On the other hand, integrating instant payment
platforms globally, also considering that those infrastructures run 24/7/365, may reduce the
fragmentation of liquidity by enabling easy transfer of funds across different timezones.
• Technical standards and schemes: The achievement of interoperability(Boar et al. 2021) between
different instant payment systems and networks is crucial for seamless cross-border transactions.
This has special value considering that instant payments operate 24/7/365 and, thus, they are
particularly fit to deliver the service on a global scale. However, obstacles, such as incompatible
technical standards, schemes, and requirements, such as durations and timeouts, make the
coordinated execution of payments between different payment systems challenging, especially
when atomicity and instantaneity must be ensured across the systems.
• Fraud and Security Risks: Instant payments may be more susceptible to fraud and security
risks compared to traditional payment methods due to the rapid processing and settlement
of transactions that reduce to zero the ex-post intervention time, during which, for example, a
fraudulent payment could be canceled. For cross-currency, where fund reversal can be even
more challenging, it is essential to have an effective mechanism capable of preventing fraudulent
transactions by identifying them promptly and with certainty before they are executed.
• Customer Identification and Verification: Verifying the identity of customers across borders can
be challenging, particularly in cases where there is limited cross-border data sharing or harmon1. In Europe, TIPS represents an exception: in addition to the Euro area, it has been adopted to settle instant payments
in Swedish Krona and, from 2025, in Danish Krona. Nevertheless, so far there are no functionalities that allow to settle
cross-currency payments between the above currencies.
ization of identification standards. Establishing robust customer identification and verification
processes is essential for mitigating the risk of financial crime in cross-border instant payments.
• Dispute Resolution: Resolving disputes in cross-border instant payments can be complex, especially when involving multiple parties across different jurisdictions. Clear mechanisms for dispute
resolution and recourse are necessary to address issues such as transaction errors, disputes over
payment authenticity, and discrepancies in transaction details.
• Infrastructure and Connectivity: The availability and reliability of technical infrastructure
and connectivity play a critical role in facilitating cross-border instant payments. Inadequate
infrastructure, including outdated payment systems and limited internet connectivity, can impede
the adoption and effectiveness of cross-border instant payment solutions.
Addressing these challenges requires collaboration among stakeholders, including governments, regulators, financial institutions, technology providers, and international organizations,
to develop standardized processes, enhance regulatory harmonization, and invest in robust infrastructure and security measures for cross-border instant payments.
The Committee on Payments and Market Infrastructures (CPMI), following the G20 leaders’
endorsement and in collaboration with international organizations such as the Financial Stability
Board (FSB), the International Monetary Fund (IMF), and the World Bank, has developed a roadmap2
to improve cross-border payments. This roadmap outlines a set of high-level goals and key focus areas for enhancing the speed, cost-effectiveness, transparency, and access to cross-border
payment systems.
The purpose of this paper is to address the interoperability challenge in the context of retail
cross-border payments and to propose a way for connecting IPSs to provide cross-border / crosscurrency payments. The proposal is to add such payments “on top” of the domestic services that
already exist, adopting an interlinking model which does not rely on any central hub, as this would
require assigning some institution the responsibility to build and operate a central infrastructure.
This interlinking model aims at defining a standard protocol to allow connected IPSs to interoperate, making it possible to process instant payments across different systems synchronously while
still preserving the nature of the instant payment in the cross-border and cross-currency scenario.
The above interoperability layer is purely technical, and it focuses on standardized messaging
formats, synchronous communication protocols, and notification management, alongside mechanisms to ensure atomic settlement. Crucially, it does not centralize regulatory functions, allowing
each IPS to operate within its own legal and compliance framework.
As an example, for dispute handling the protocol supports end-to-end synchronous notifications and recovery mechanisms to enhance traceability and auditability. Nonetheless, substantive
dispute resolution remains the responsibility of the transacting parties and their respective authorities.
Although it is outside the scope of this document, a further step in the direction of having a
solution ready to work is to set up an investigation of the detailed aspects of the proposal through
a technical proof-of-concept.
The cross-border payments today
Cross-currency payments are typically based on a set of bilateral account relationships (correspondent banking model) and using a variety of intermediaries, in particular when the payment
originates from (or is directed to) smaller intermediaries who do not have such bilateral account
relationships with foreign intermediaries, and this leads to settlement risks and reduces efficiency
(in terms of cost, speed, accessibility, and transparency).
Correspondent banking is a relationship between two financial institutions, typically banks,
2. https://www.bis.org/cpmi/cross_border/programme.htm
where one bank (the correspondent bank) provides services on behalf of another bank (the respondent bank). This relationship facilitates transactions and financial services for respondent
bank clientsations where it does not have a presence or where its presence is limited. The following
parties are involved:
• Correspondent Bank: This is usually a large international bank that has a broad network of
branches and correspondent relationships around the world. They provide various services to
smaller banks.
• Respondent Bank: This is typically a smaller financial institution that does not have a presence
in certain regions or countries where its clients need services. The respondent bank relies on the
correspondent bank to facilitate these transactions.
The correspondent banks facilitate the processing of payments, such as wire transfers and clearing
of checks, on behalf of the respondent bank and its clients. They assist in converting currencies,
allowing clients of the respondent bank to conduct transactions in different currencies.
Banks communicate with each other through various means, including SWIFT (Society for
Worldwide Interbank Financial Telecommunication) messages. Settlement of transactions between
correspondent banks typically occurs through nostro/vostro3 accounts that they maintain with
each other or through clearing and settlement systems.
In this paper, we define “cross border payment route” a specific pathway or channel through
which funds are transferred between two parties in different countries or regions. These routes
represent the trail along which financial transactions flow, typically involving multiple correspondent banks to facilitate cross-border payments. When a payment is initiated from one country to
another, it may pass through multiple correspondent banks along the route before reaching its
final destination. Each correspondent bank on the path plays a role in processing, routing, and
settling the transaction. Cross border payment routes often involve currency exchange, especially
if the originating and destination countries use different currencies. Correspondent banks within
the route may offer foreign exchange services to facilitate the conversion of currencies during the
transaction. Correspondent banks may charge fees for their services in facilitating transactions
within payment routes. These fees could include transaction fees, currency conversion fees, and
other charges associated with cross-border payments. The efficiency and speed of transactions
within routes can vary depending on factors such as the number of correspondent banks involved,
the effectiveness of communication and settlement systems, and any regulatory requirements that
need to be met.
However, relying on correspondent payment relationships leads to many problems such as high
costs due to fees to be paid for their use and delays in payment routing caused by various factors
such as time zone differences, banking holidays, manual processing, and inefficient communication
between banks. In addition, the payment chain may often be quite long, involving multiple correspondent banks. Managing relationships with these different parties and navigating the various
steps in processing cross-border payments can be complex and time-consuming. This complexity
can lead to errors, misunderstandings, and inefficiencies in the payment process. Correspondent
banking relationships are subject to regulatory requirements and compliance standards imposed
by authorities in different jurisdictions. Ensuring compliance with anti-money laundering (AML),
know-your-customer (KYC), and other regulatory obligations can be complex and costly for banks,
particularly if they operate in multiple countries with differing regulatory frameworks. Failure to
comply with regulatory requirements can result in fines, legal penalties, and reputational damage. Addressing these challenges requires collaboration among financial institutions, regulators,
and other stakeholders to improve the efficiency, transparency, and accessibility of cross-border
3. “Nostro” and “Vostro” are two different terms used to describe the same bank account. The terms are used when one
bank has another bank’s money on deposit, typically concerning international trading or other financial transactions. For
further information, please see: (ECB, n.d.) (Bindseil and Pantelopoulos 2023) (IOSCO 2012) (CPMI 2016)
payments. This may involve leveraging technology, streamlining regulatory processes, enhancing
cross-border infrastructure, and promoting greater cooperation and standardization within the
financial industry.
Architectures and interoperability
The traditional correspondent banking model has been complemented by further solutions based
on: i) interlinking between domestic payment systems belonging to different currency areas; ii)
centralizing payments onto shared platforms, where settlement accounts of participants from
different currency areas are hosted.
Centralized platforms are those where intermediaries’ settlement accounts are held in a central
technical infrastructure. Payment Service Providers (PSPs) usually access these platforms remotely,
meaning that the platform and the PSP are located in different jurisdictions. This results in several
consequences, including the need for intermediaries to adapt their procedures, standardization of
processes, and a higher degree of regulatory convergence. In addition, it requires more complex
governance and oversight structures, which have led to their adoption in only those regional areas
that are already integrated from a financial, technological, and regulatory standpoint, such as the
European Union and the SEBC4 .
The term multilateral platform refers to a centralized platform that is designed to support
operations in a multi-jurisdiction environment (CPMI 2023) without requiring ex-ante standardization of processes or regulatory convergence. However, creating and maintaining such a platform is
complex. It requires addressing the intricate dynamics stemming from diverse markets and the
governance challenge. Furthermore, the centralized approach presents a risk of reduced agility and
responsiveness to change, which can lead to increased costs and prolonged adaptation periods.
As a result, such a platform may become inflexible and ultimately impede market dynamics and
innovation.
Instead of building new centralized platforms, whether multilateral or not, already existing
systems can be interconnected each other, thus interlinking them.
Bilateral interlinking refers to the topology where two entities establish a direct relationship
with each other to make it possible to interoperate without relying on intermediaries.
On the one hand, creating a network of bilateral interlinking for connecting existing systems5
across multiple areas can become difficult to manage as the number of links grows. Any changes in
the domestic system may require several adaptations and can be costly and prone to operational
risks for the interconnection components. On the other hand, in a cross-jurisdiction environment,
interlinked systems establish technical links, common standards and underlying agreements to
make systems interoperate with each other “as if they were the same system” minimizing the
adaptation required.
The evolution of bilateral interconnection leads to the hub-and-spoke model, where bilateral
links are replaced by a standardized connection to one or more central hubs. The central hub may
be designed with the purpose of realizing the conversions among the different local standards
for messages, synchronizing the status of the different systems allowing atomic transactions (e.g.
all-or-nothing payments with legs settled on different systems), to propagate information among
interconnected systems (e.g. to allow remotely carrying out of operations such as AML/CFT using
4. In EU, the T2 platform is an example of centralized and multi-currency platform made possible due to the high
integration of the area.”
5. Unlike what happens for centralized platforms, whose participants are PSPs, the participants of this infrastructure are
other systems (or other centralized platforms).
remote information. 6
The multilateral paradigm appears to be more suitable for a global scale and multi-jurisdiction7
environment. However, there are still some challenges that need to be addressed to make such a
platform more effective.
In the following figure, the different types of architectures, centralised, interlinked, and huband-spoke, are depicted, both in a domestic and multi-jurisdiction context.
Figure 1. Types of architectures
The following scheme recaps the taxonomy of the types considered so far.
Types of architectures for interoperability
Architecture
Interlinking
Centralized platforms
(Centralized) multilateral
Bilateral interlinking
Hub-and-spoke
6. To simplify the design of such a structure, the centralized components, the hub, may expose Application Programming
Interfaces (APIs). This approach allows for a certain degree of standardization and was adopted in the Nexus project by the
BIS-IH of Singapore, involving instant payment systems.
7. It is worth mentioning a further type of architecture that is based on the decentralization of its structure and governance,
the distributed ledger technology (DLT) architecture and blockchain. In this architecture, a platform is based on a set of
standardized nodes that implement a shared protocol and provide any user with a single “shared truth” delivered as the
ledger, which is physically stored on the nodes. Any transaction aiming at changing and forming the “shared truth” need to
be validated by special actors called “validator nodes”, acting in accordance with the protocol. A DLT/blockchain network
can be either “permissionless” or “permissioned”; a typical network is permissionless, where all nodes can contribute to
validate transactions, by reaching consensus with other nodes. Conversely, in a permissioned set-up, the validator nodes
are pre-determined. In addition, a DLT/blockchain (Butijn, Tamburri and Heuvel 2020) (Ghiro et al. 2021) can be public when
there is no limited access and any user can access the ledger and can propose updates to the validators. For the purpose
of this work, a distributed ledger/blockchain platform can be considered as a possible shape of a multilateral platform
as, in this context, this (especially a permissioned set-up) can be seen as standing in an intermediate position between
centralized and interlinked models. A permissioned DLT/blockchain allows for a balance between elements of centralized
governance and elements of decentralization.
In general, the interlinking approaches (either bilateral or hub-and-spoke) have advantages in
terms of i) speed of implementation; ii) lower adaptation costs for national financial communities,
which can keep processing payments using “legacy formats” that are converted into a new common
standard by the interconnection components; in addition bilaterally interlinked systems have a
relatively simpler governance and oversight structures compared to hub and spoke and centralized
platforms.
The architecture types described above can be compared, with respect to several characteristics,
as follows:
Governance: Concerning governance choices, two categories can be identified:
• Centralized governance platforms (e.g., the CLS system), which need a clearly identified subject
in charge of defining and enforcing the participation rules, supporting operations, and providing
all the required services, such as applying the exchange rate and delivering to the participants all
the information they need;
• Decentralized 8 governance platforms, which are made of a network of processing nodes located
at the participating institutions (or part of them) and whose functioning is governed by common
and shared rules but without requiring to assign a pre-eminent role to any owner of the network:
the operation of each node falls under the responsibility of the hosting participant.
A cross-currency / cross-border scenario is “multi-authority” as many authorities are responsible for applying different types of controls and for different policy implementations, identifying
such a pre-eminent role is difficult and, moreover, difficulties can rise in agreeing on a common
governance9 . Consequently, this leads to preferring an interlinked model, where the interconnection of autonomous systems may better allow the national authorities to keep control over the
local payment schemes and central banks to maintain control over transactions involving their
own currency. This does not exclude, when possible, the adoption of some integrated solutions
to seek the efficiency of an integrated platform, especially in the more economically connected
regions and where the regulations and market practices are better harmonised.
Scalability: It is intended as the capability to support an increasing number of users10 and
workload just increasing the number of dedicated resources. It is different from speed (which is
relevant as well to ensure low latency,11 so short waiting time to final users). Scalability holds
particular significance in retail payment systems, where transaction volumes are substantial. With
the emergence of instant payments, the system’s responsiveness becomes equally essential.
Centralised platforms can be scalable, even though they can only scale “vertically”12, and fast.
Bilaterally interlinked systems can also be fast (provided that each of them can scale vertically).
Still, the whole interlinked system does not scale, as the number of links grows more than linearly
when the number of connected systems grows. This issue does not belong to the hub-and-spoke
type, where the number of links is linearly dependent to the number of nodes. Distributed ledger
can scale-up, even though to process high workload it requires to set up a hierarchy of different
8. The classification between centralized and decentralized systems we adopt in this document refers to a governance
perspective: a centralized system is owned by a single entity or organization, while in a distributed system the ownership is
spread over some “well known” organizations (i.e. like a consortium); in a decentralized system, ownership is spread over
many entities, not mutually trusting and possibly unknown to each other.
9. This is becoming even worse in the current geopolitical frame, where the role of the multilateral organisations is
progressively becoming weaker.
10. Users are participants to a platform who are supposed to generate requests to be processed. In this meaning, any
participant not generating requests, such as validators of transactions in case of a DLT/blockchain platform, is not considered
a user.
11. To this extent, distributed ledger networks have usually higher latencies than other systems (and this is caused by the
need to reach “consensus” among nodes and allow validation of transactions) but this does not imply they are not capable
to increase their workload by adding new processing nodes (under the assumption that the validator nodes remains stable).
12. To scale vertically, means being only able to bear an increasing workload by employing more powerful hardware. As
opposite, to scale horizontally, or scale-up, means to be able to cope to additional workload by just adding more processing
nodes. In principle, vertical scalability is a flaw: increasing the computational resources assigned to the existing node is
expensive and could encounter technological limits.
network and ledgers (impending transparency across ledgers); nevertheless an important limit of
this architecture is represented by speed as the consensus algorithms does not allow to reach low
latency per each transaction even in a set-up designed for high volumes.
Overall costs: When evaluating this dimension, the following facts must be taken into account:
• Centralized platforms are complex and expensive (to realize and to operate) as they must satisfy
requirements stemming from a heterogeneous market and from several jurisdictions, adding
complexity;
• Bilateral links may be, individually, less expensive. However, the number of links required to
connect an IPS to the others grows linearly with the number of interconnected systems13 ;
• Multilateral interlinking, as well as bilateral interlinking, may allow savings by reusing already
existing local systems;
• Distributed ledgers leverage on standardized software and protocols, whose operation is distributed in a (potentially) high number of inexpensive nodes;
• Hub-and-spoke systems lie in an intermediate position between centralized systems and DLTs.
In retail payments, minimizing the cost per transaction is essential since individuals shouldn’t be
burdened with high expenses for a basic service.
Transparency: It refers to the capability to make participants easily inspect the ledger data,
and avoid the costs of reconciliation between different systems that are usually obtained using
dedicated reports or queries, and often requiring manual intervention. Each type of architecture
potentially allows for a certain level of transparency, but it needs to be ensured by features added
“on top” of the system with additional costs14, whereas distributed ledgers provide it inexpensively,
“by design”. A Hub-and-spoke set-up, having a common infrastructure, can implement a common
repository, reducing the cost for participants to reconcile with each system they are participating
Resilience: It means the capability to continue operating even in adverse conditions (either
stemming from a deliberate act – providing cyber resilience -, or an incident). To this extent, the
degree of distribution of the system influences the level of such desirable property. Centralized
platforms deliver, in principle, the lower level of resilience and,at the opposite side15 distributed
ledgers are, potentially, the most resilient architecture. In retail services, operating 24/7/365 is
essential. Consequently, the architecture should allow to perform housekeeping and maintenance
activities, as well as upgrades such as the deployment of new versions, without disrupting the
service.
The table below outlines the key characteristics discussed previously and how they pertain to
the architectural types introduced at the beginning of the chapter.
(*) A Centralized Platform could achieve individually a high throughput. Many bilaterally interlinked
systems naturally process transactions in parallel, achieving globally the sum of throughputs.
(**) The single system or the hub are potentially single point of failure.
13. The total number of links required to create a network of N fully interconnected IPSs is N (N2−1)
14. These costs can be rather high, considering that a centralized platform typically requires its participant to reconcile
(e.g. daily) they internal ledger with data of the platform, establishing specific procedures and arrangements to cope with
the event of misalignment.
15. due to their distribute topology, where each node can replace a failing one and, as far as cyber resilience is concerned,
due to the “byzantine fault tolerant” (BFT, Lis the property of a distributed system that enables it to function correctly and
reach consensus even when some nodes exhibit arbitrary (byzantine) faults, including malicious, faulty, or inconsistent
behavior. It ensures reliability and security in adversarial conditions. For more info see: https://dl.acm.org/doi/abs/10.
for instance, the centralized platform), but they are not provided “by design” as in (many of) the DLTs.
Table 1. Architecture types comparison
Multi-authority
governance
Speed
Scalability
Overall costs
Transparency
Resilience
Centralized
Multilateral
Platform
Difficult
Bilateral
Interlinking
Hub-and-spoke
Distribute
ledgers
Easier
Difficult
Easier
High(*)
Low(**)
High(*)
Medium
Medium
Possible
Low(**)
Medium
Which interoperability model for cross-border instant payments?
When considering instant payment systems it’s important to examine a model based on a shared
central platform, especially a multilateral platform, as it could ensure the low latencies which are
essential to enable the synchronous user experience that end-users demand, and high volumes,
needed for a retail payment system, which is supposed to be used by a large number of individuals.
However, it’s important to note that a central platform may not be the most practical solution
for providing services across different jurisdictions. The variety of jurisdictions presents various
governance challenges, and carrying out a harmonization and standardization project at international level presents objective difficulties that would make the undertaking extremely demanding.
Furthermore, to protect investments in national systems that have only recently been implemented,
it’s better to choose a more pragmatic path that favors the integration of existing systems rather
than their replacement.
As a result, it’s widely preferable to develop an effective model that seamlessly integrates the
existing local instant payment systems, and a hub-and-spoke architecture would be the preferred
design. In this design, a central hub would be responsible for bilaterally adapting the two IPSs
involved in a transaction.
Moreover, it may be challenging to identify a supra-national entity willing to take on the role of
an element of integration and catalyze the interest of the various national stakeholders in favor
of a common infrastructure of adequate scale. The role of the hub operator in the hub and spoke
model is to interconnect the different IPSs by providing settlement message routing capabilities.
Essentially, a network of IPSs is created that always communicates only through the central hub.
This network topology could be superseded by eliminating the hub and by establishing a network
of individually interlinked IPSs that could receive and forward settlement messages originated and
directed to other IPSs by effectively assuming the role of transit nodes in a network of settlement
systems.
We can define this model as the IPS Network model, shown in Figure 2. This interconnection
model enables the creation of bilateral links that utilize the IPS network to transport settlement
messages. It also allows for progressive network construction that can expand and reconfigure
over time based on the number of adhering IPSs.
The network of IPSs does not need to be full-mesh, as depicted in Figure 2. Instead, different
network topologies can be adopted to, for example, minimize the number of links or hops required
to connect the two IPSs between which a bilateral link needs to be built.
Figure 2. The “IPS network model”
The reasoning behind this choice is primarily pragmatic: while both multilateral platforms and
the hub-and-spoke model can achieve high levels of efficiency, the absence of a supranational
authority and the current lack of multilateral agreements and arrangements make it most effective
to develop a well-structured network of interconnected bilateral systems. More into details, the
reasoning drivers are the following:
• An interlinking model leverages existing platforms and minimises the requirement for business
and legal harmonization16 by each community, protecting investments supported by the authorities and financial communities.
• Adopting a multilateral interlinking model does not prejudice future evolution towards the huband-spoke model, creating one or more hubs if and when entities emerge capable of gathering
the necessary consensus.
• An incremental and progressive transition towards a multilateral model can be activated starting
from the adoption of bilateral connections, which, based on the value generated, can achieve
interoperability between regions with greater commercial exchange.
As noted above, the adoption of bilateral links does not scale well as the number of links grows
quadratically with the number of participants. The proposed network model aims to minimize
this inefficiency, allowing the utility of each bilateral link to be maximized and its marginal costs
minimized, thus facilitating the transition from a model based on bilateral links to a model based
on multilateral links. With this approach, we can achieve a robust and efficient interlinking arrangement that meets the needs of users and businesses alike.
4 The proposal: An “IPS network model” for interlinking local Instant Payment
Systems
The following part begins with an introduction outlining the widely used “correspondent banking
model” (Figure 3) before analysing the possible evolutions of interlinked systems. The analysis
starts with a model that relies on a common intermediary — a participant in both interconnected
systems (Figure 4) — and progresses to a model in which bilateral links are realised and controlled
directly by each system (Figure 5). Furthermore, Chapter 5 delves into the “IPS interlinking protocol,”
detailing the proposal at both the application and network levels. At the application level (Section
16. Nevertheless, aside from business interoperability (as proposed in the next chapter), AML/CFT and fraud controls
should be aligned.(Boar et al. 2021)
5.1), the protocol aims to harmonize the behaviour of IPSs, enabling them to process transactions
jointly while ensuring a unique and consistent outcome across the different systems. At the network
level (Section 5.2), the proposal seeks to maximize the efficiency of each bilateral link by creating
“logical connections” over network links, thereby reducing the proliferation of links required.
The predominant model adopted for cross-border payment exchange on a global scale is
known as “correspondent banking” and is based on reciprocal account relationships. This model
(see Figure 3) relies on intermediaries that facilitate the transfer of funds and currency exchange.
In this process, the sender initiates a payment order through their bank, which is subsequently
transmitted through multiple intermediaries responsible for ensuring transaction settlement and
forwarding the relevant information to the final recipient. In addition, these intermediaries provide
notifications regarding the transaction outcome. While the sender’s and recipient’s banks may
maintain a direct account relationship (correspondent banking model), it is common for them
to depend on an intermediary. This intermediary plays a crucial role in ensuring compliance
with regulatory requirements across different jurisdictions and managing currency conversion.
Specifically, the intermediary purchases the currency from the sender’s bank and sells the required
currency to the recipient17, thereby facilitating the completion of the transaction.
A potential development of the basic correspondent banking model, is the Single Access Point
model (CPMI 2022), which relies on an intermediary (see Figure 4) that participates to both systems,
facilitating seamless transactions between them.
Figure 3. Payment route with correspondent banking
A critical element of such a type of bilateral connection is indeed the need for a “pass-through”
intermediary who is both in charge of connecting the systems and keeping an account relationship
to ensure currency conversion between the two jurisdictions, by selling and buying the different currencies of the two legs of a cross-currency payment. This actor participates in the two
interconnected payment systems and is also named as “cross-currency PSP”.(Renzetti et al. 2022)
When compared to the simple use of a correspondent banking model (figure 3), interconnected
systems (figure 4) should increase payment speed for cross-currency and reduce costs by reducing
the number of links and institutions involved: 18 in fact, the intermediary in middle of Figure 3 is
intended to operate for the benefit of the two operators, the sender and the recipient, while in
Figure 4 it operates for the benefit of the systems A and B, therefore for the two entire communities
of participants.
The next stage in development, illustrated in Figure 5, presents a model in which the two systems
are directly interconnected, enabling interoperability without the need for a shared intermediary
participating in both systems.
17. Often, the trade is done in exchange for a third currency, named “vehicle currency”. This is especially common when
the currency pair is not among the most traded.
18. It should be noticed that this type of solution may resemble the “hub-and-spoke” model mentioned above, looking
at the intermediary as the hub and the participants as the spokes. Nevertheless, the hub-and-spoke model is meant to
interconnect payment systems, not participants, and here the two platforms are still bilaterally connected.
Figure 4. Payment route with Single Access Point
The next stage in the development, which will be further described in the next paragraphs,
depicts a model (see Figure 5) in which the two systems are directly connected, enabling interoperability without the need for a shared intermediary participating in both systems. The two systems,
in addition to being connected at network level, must operate in accordance with the same specific
application interoperability protocol (from system to system, while in the previous model it was
possible to rely on the standard mode of communication between system and participant).
In the last model, which is in our proposal and that will be further described in the next chapters,
the role of the provider for foreign exchange service is kept as separate from the role of “connection
provider”,19 thus potentially increasing the competition among the possible market players, as
each participant can choose among (potentially) multiple FX agents. This streamlined setup can
contribute to lower unit costs by reducing the bind of different functions involved in the payment
chain.
The proposed “IPS network model” fits in this framework.
Figure 5. Payment route on interlinked systems
The key feature of this model is that it represents an advancement beyond a network of systems
that are only indirectly connected (i.e., linked through shared participants across system pairs).
This model, however, requires the adoption of interoperability rules (analysed in detail below) and,
consequently, common standards. While this imposes additional burdens and costs, it ensures a
higher level of service, such as, in this proposal, guaranteeing the atomicity of end-to-end payments
“by design.” Moreover, as the number of interconnected systems increases, the associated costs and
burdens tend to decrease. In summary, given the absence of a centralized governing framework,
rather than building an expanding network of uncoordinated links, this model offers a sustainable
and rational approach to enhancing the harmonization and overall effectiveness of the network.
In the following sections, the proposal for a way to make the different IPSs interoperate, in the
framework of the “hubless model” shown in Figure 2, with each other will be discussed.
19. As a general goal, a platform should aim at separating the different service involved in a business case: trading
currencies (FX), clearing, settlement, should potentially be in carried out by different entities to foster competition and to
enable innovation, by promoting specialization of roles.
The proposal: service interoperability and networks interoperability
The proposal is based on two pillars: one dealing with the applications, the messages and the
payments and the other aiming at optimizing the network level, making the communication links
between systems more effective and “reusable”. First, in order to make different systems, located
in different regions, able to interoperate,(Boar et al. 2021) it is essential to establish a common
standard that makes it possible to provide business services to customers, i.e. to send and receive
payments, to send and receive payment notifications, and other “off-ledger” communications such
as payment investigations and address resolution queries. At this level, the two applications can
“understand” each other and can cooperate to accomplish a unique task and to deliver a unique
service (typically, a payment) to the users, perceived by the users as unique.
Secondly, at a lower level, there is the need to ensure communication among the infrastructures,
to let them exchange all the messages that support the above business communications. At each
of the two level, we propose a dedicated protocol.
Figure 6. Two-layers models
The macro tasks to be accomplished to define the interoperability model are the following:
• Define a common standard for messages, both for service invocation and for responses, that
each participating IPS should adopt when sending messages to other IPSs and when receiving
messages from other IPSs. Format conversion of messages, when needed to cope with specific
national customisations, should be carried out by each participant;
• Include the institutions providing FX and currency conversion services, for cross-currency arrangements. The institutions should take part in the network and their related messages should
be included in the common set of standard messages.
• Route messages over specific network links and adopt a common network definition, to provide
connectivity among all the IPSs participating in the initiative;
The network layer: messages
Interconnecting the participating IPSs by establishing bilateral connections increases quadratically
the complexity of the overall network when the number of participating IPS increases. Despite this
exorbitant number of links, the availability of a single link still affects the overall availability of the
service, i.e., not only would the end user not be able to send a payment if the sending and receiving
IPS are not operational, but also if the link involved in the payment is not working. On the other
hand, the model proposed here overcomes the need to have a central hub, so a central entity is
responsible for its realization and operation.
Consequently, the proposed model for the network still relies on bilateral links but adopts some
measures that aim at making the network more resilient and efficient: each link should be used as
a “recovery path” for other bilateral links that (i) are temporarily unavailable or (ii) has not been
built because the volumes of bilateral exchanges did not justify the investments.
The service layer: payments and related services
The purpose of interconnecting IPSs is to allow users to pay across different currencies, preserving
the user experience of “domestic” payments, thus ensuring synchronous payment logic, notifying the originator when the payment is successfully finalized, with funds made available to the
beneficiary, or rejected.
To realize such functions, several services shall be provided across the different IPSs: (i) IPSs
shall provide payment service (broken down into reservation of funds, settlement, and timeout
management) and provide the capability to perform schema conversion to send payments to a
foreign IPS, (ii) FX providers shall ensure functions to publish FX rates and provide intermediation
for selling and buying currencies, (iii) directory services shall provide “look-up” functions to allow
the use of domestic aliases (such as mobile numbers) across the different jurisdictions.
Actors and roles
Instant Payment Service, IPS: It is a local retail Payment System that operates by providing
atomic settlement and real-time settlement on a gross (i.e., one-by-one) basis of the two
legs. It also ensures full synchronous notification of the end-to-end transaction to the
counterparts, taking care of both the settlement and matching services, i.e. it (i) books
the funds on the bank’s accounts if and only if both the counterparts have authorized the
booing, (ii) it provides immediate notifications that make both the counterparts aware of
the final result of the transaction, either positive or negative and (iii) it reaches a final status
of the end-to-end transaction within a pre-defined time interval.
Alias lookup Service: It is a local directory service that allows the Originator of the payment
to retrieve information about the beneficiary customer. It is typically used for converting
an “alias” of the beneficiary, such as the phone number, an email address, or a generic
nickname, into the account identifier or any other unique identifier suitable for addressing the fund transfer. More generally, this service may be used to retrieve any additional
information to attach to the payment request message.
Payment Service Provider, PSP: It is the participant (typically, a bank) to the IPS, either
the source or the destination of the payment. Both the source PSP and the destination PSP
need to have an account held in the relevant IPS.
Settlement Account Provider (SAP) and Foreign Exchange (FX): The Settlement Account
Provider is the participant who owns the account in the IPS. The SAP of the Source PSP
must allow the Source PSP to instruct payments that debit his account in the Source IPS,
the SAP of the Destination PSP will receive the funds on behalf of the latter in his account
held in the Destination IPS.
In the model proposed, the Source SAP is in charge of the FX currency conversion: a the
Source PSP credits the payment amount to the Source SAP as a domestic payment in the
Source IPS. Then the Source SAP converts the amount from one currency to the other and
appends the converted amount to the payment message sent abroad. When the payment
message arrives at the Destination IPS, then the Destination SAP is debited in favour of the
Destination PSP. b
Sender and Recipient: The sender customer is the originating payer, being an individual
or a firm customer of the Source PSP, and entering the payment. The recipient customer is
an individual or a firm that the payer intends to pay and who receives the funds being a
customer of the Destination PSP.
a. In this case, it receives the amount in the source currency directly from the Source PSP and pays the amount
in the destination currency to the Destination PSP, within the same IPS of the counterpart. Nevertheless, it is also
possible to consider the case in which the FX Provider is not a member of the IPS. In such a case the SAP is simply
a participant that acts as a “liquidity provider” of the PSP and the relationship between the SAP and the external
FX provider can, as always, be ensured by a couple of “nostro/vostro” accounts.
b. At the end of each payment, the Source SAP increases its debit vis-a-vis the Destination SAP, who correspondingly increases their credit vis-a-vis the Source SAP employing a couple of nostro/vostro accounts.
IPS interlinking protocol
To ensure that various IPSs, directory systems, and FX providers can interact with each other without
the need for a central hub, it is important to define and adopt common standards that govern the
different levels and enable schema conversion for all interconnected systems. Both the sending
and receiving PSPs in a domestic payment are required to adopt the same schema. This applies to
payments as well as related services like the alias lookup service.
Figure 7. Domestic payment schema
In the figure 8 below, two IPSs are interconnected, at network level, through a dedicated link,
enabling bidirectional transfer of orders between I P S A to I P S B and vice versa. Furthermore,
the alias lookup services provided by the two systems can be remotely accessed, and the foreign
exchange service (F X ) is available.
Figure 8. Cross-jurisdiction payment schema and bilateral link
As a general case, the schema adopted by the two jurisdictions has some differences. When
a payment is sent from I P S A to I P S B, a schema conversion step is necessary, provided that the
sending IPS shall fulfill the rule of the schema adopted by the recipient’s IPS.
In the following figure 9, the schema conversion is shown. The various systems must implement
the conversion logic, which is delegated by each IPS to a specific component plugged into the
system, known as the “IPS Border Gateway” (BGW)20 .
Figure 9. Schema conversion.
The service interoperability protocol
The payment flow
In this section, the application protocol for payments is proposed, and the following figure 10 shows
the flow of messages needed to send a payment from a customer in Jurisdiction A to a customer in
Jurisdiction B.
The flow is derived from the proposal prepared for the Nexus Project (BIS 2023b) and it is based
on the concept of “nested payments”: the sending IPS keeps the payment “on hold” (i.e., the funds
remain reserved) until the payment is finalized in the receiving PSP. 21 . The dialogue between the
customers and their PSP is out of the scope of this flow as it is out of the perimeter of their relevant
interbank scheme.
When implementing the protocol for payments, the ISP shall be able to execute two basic
primitive functions: the reserve function, which makes funds unavailable to other payments, and
earmarking those funds only for the subsequent settlement function that makes the payment
as final22 or for the cancellation of the reservation triggered by the failure of the transaction.
The assumption is that all the IPSs should already allow such a basic function to provide atomic
20. For sake of simplicity, in the following paragraphs it is assumed that the gateways connect IPSs and directory systems.
The adoption of a similar component at the side of FX providers is not explicitly mentioned, as these participants are not
required to interconnect with each other, but only to provide their service according to standardized methods.
21. This implies necessarily that the payment in the sending IPS must not be subject to the timeout, i.e., the sending IPS
must wait for the receiving IPS answer (either positive or negative) in order not to make the payment “trapped” into an
uncertain status. See also 24
22. This is equivalent to an atomic transaction that drops the reservation and transfers the fund between the two accounts
involved in the payment.
settlement of the domestic instant payments.
Figure 10. Cross-currency payment flow.
The following is a description of the steps carried out to link together the payments settled by
the two IPSs:
1. When the source PSP receives a payment order from its sending customer, it sends a standard
payment instructing message to its IPS, following the rules of the schema it belongs to and, in
addition, appending the cross-currency specific information (e.g., the destination jurisdiction
and the final currency for the credited funds);
2. The IPS in the sending jurisdiction performs its checks and reserves the funds on the account of
P S PA : after it asks the Service Account Provider S AP A (whose identifier has been provided by
P S PA in the instructing message), to authorize the future credit of the funds on its account (the
settlement takes place only at the end of the flow, after the success of the “abroad” / B part of
the payment);
3. S APA authorizes debiting the A currency on its account; S AP A appends to the message the
amount converted from the currency of Jurisdiction A to the currency of Jurisdiction B;
4. I P S A sends the payment instruction abroad, appending the new amount converted by S AP A ;
to do so, it (i) decides the routing path to reach I P S B and (ii) applies the specific transformation
to the instructing message (the transformation is specific to Jurisdiction B);
5. I P S B notifies S APB asking to authorize the debit on its account;
6. S APB authorizes to settle (debit) the operation on its account. Here, S AP B does not act as
an FX agent (it is supposed to carry out FX only for payments flowing from Jurisdiction B to
Jurisdiction A, not shown here). In any case, by authorising to debit its account, S APB accepts
the payment at his side (with this, the acceptance can be extended to the FX rate applied);
7. I P S B reserves the funds on the account of the S APB (whose account will be debited in Jurisdiction B currency); after, I P S B forwards the payment instruction to P S PB, asking to authorize
the operation as well;
8. When P S P B authorizes the payment (in addition to S APB ), I P S B makes the debit on the S AP B
account and the credit on the P S P B as final;
9. The settlement confirmation is sent to P S PB and S APB ; In addition, it is sent to I P S A to finalize
the operation that is still open (funds are only reserved in I P S A, and there is no timeout there);
10. The fund’s reservation on the P S PA account is settled and credited to the S AP A account; afterward, the end of the whole operation is sent to P S PA and S AP A . 23
In the event of a malfunction that prevents the receipt of the payment notification (e.g., the 9c
notification is never received), a specific flow allows the Source PSP (or the SAP) to request the
re-transmission of the lost notification.
Account view
The booking on accounts held in I P S A and I P S B are shown hereafter: the number (n:)
refers to the step, listed in the flow described in Fig.10, where the booking took place, x
and y are the sent and received amounts (assuming, for sake of simplicity, that no fees are
charged by S AP A and S APB ), and A is the currency of the amount x and B is the currency
of the amount y .
I P S A ledger
P S PA
I P S B ledger
S AP B
S AP A
P S PB
(1:) -x A (reserved)
(6:) -y B (reserved)
(8:) -y B (settled)
(9c:) -x A (settled)
(8:) +y B
In addition, if S APA and S AP B are separate entities, they shall have account relationship
to each other, outside I P S A and I P S B . Under this hypothesis, their nostro/vostro account
would be booked as follows:
S AP A ledger
S APA
S AP B ledger
S APB
S AP A
(9b:) -x A
(10b:) +x A
S AP B
(9b:) +y B
(10b:) -y B
Notification solicitation flow
As a typical condition in distributed state systems, it might happen that as a consequence of some
unexpected event (e.g., a technical outage, a network glitch, or delay) the Sending PSP does not
know what the final status of some payment is in the remote system. This might happen if, for
instance, the payment notification 9c in figure 10 is lost at whatever point. In such an event, before
taking any action,24 P S PA must be aware of the status of the payment in the remote ledger of I P S B .
23. In the event of a (technical) failure that makes it not possible to finalize the last settlement, the operation should be
reverted to Jurisdiction B, as the negative confirmations in Jurisdiction A are not enough to roll back the whole operation.
In such an event, which from a logical viewpoint should never happen, an ad-hoc process should be followed to revert the
funds transfer in both I P S A and I P S B systems.
24. As an example of assumptions that the Sending PSP should never take in the absence of information about the status
of the remote leg of the payment, consider an individual who is paying for a purchase in a physical shop. Should the payer
be allowed to get the good he/her is supposed to have paid for?
• If yes and the payment has been refused at I P S B, then the funds will sooner or later return to the payer’s account;
• If not and the payment has been settled at I P S B, then maybe he/she pays again (suppose, using a different instrument
such as cash), but in this way he/she pays twice.
This can be done by making the final notification to be re-transmitted, as shown in the following
description.
Figure 11. Solicitation flow.
11. The Source PSP (or S AP A ) sends a message requesting the re-sending of the notification of a
given payment (providing the payment-id);
12. The IPS forwards the requests, converting the message into the format of I P S B, if needed;
13. I P S B searches for the given payment and sends out a copy of the settlement confirmation
message;
14. The copied settlement confirmation message is processed as if it were the missing one.
The alias lookup flow
In addition to payment, a further optional service that is linked to an instant payments system is
the alias lookup. As for the payment, in a cross-jurisdiction scenario, before sending a payment,
the sender in Jurisdiction A, needs to translate the alias of the beneficiary customer in Jurisdiction
B. The BGW is therefore able to route the request for alias lookup translation from one jurisdiction
to the other and to send back the answer accordingly. The following figure shows the flow of
messages.
In all cases, any assumption can lead to an inconsistency in the ledgers.
Figure 12. Alias look-up across jurisdictions.
1. The Source PSP needs to “enrich” a payment order by translating an alias of the beneficiary into
the relevant account identifier valid within the beneficiary’s jurisdiction (Jurisdiction B). To do
so, P S P A sends a look-up request to P S PA, using the standard in use within Jurisdiction A;
2. The local Look-up system LU S A takes care of the conversion of the message format and sends
the translated message to LU S B ;
3. LU S B search for the account identifier linked to the alias of the beneficiary and back the response, using the LU S B message format;
4. Again, LU S A takes care of the translation and transforms the response in the format in use
within Jurisdiction A, then sends the message to the originating PSP (P S PA ).
A more effective network layer: the network interoperability protocol
The number of bilateral links needed to connect IPSs increases quadratically when the number of
IPSs increases. To achieve e more effective network topology, the links should be used to transport
payment and service messages, minimizing their number. The jurisdictions, consequently, may be
connected indirectly.
In the following figure 13 Jurisdiction A and Jurisdiction B do not have a dedicated link to
connect each other; they use Jurisdiction C to route all the messages between them. Jurisdiction C
does not provide any service outside of the connectivity, it acts as a pure pass through.
Figure 13. Indirect link.
In the above case, an indirect links look has been established. It is important, in such a case, to
note that the payload of the messages flows through Jurisdiction C in the above figure. First of all,
within Jurisdiction C nobody should be entitled to read the business content of any message that
is simply routed. In the following figure, the payload of the message is bilaterally encrypted and,
consequently, only the final recipient of the message can decrypt and read it.25 Provided that the
message is not publicly readable anymore, all the information needed to route the message and
properly deliver it to its final recipient must be extracted and written into a dedicated header.
Figure 14. Indirect link with schema conversion, payload encryption, and message header.
25. end-to-end encryption should be bilaterally agreed by the two counterparts: the usage of keys, certificates, and all the
related processes, are not in the scope of the current proposal
Such a header contains information such as the identifiers of the originating PSP and the
destination PSP. It also specifies the type of message transported: payment-related (pacs.008,
pacs.002, etc.), alias lookup or messages related to the network and routing (request to add/remove
links, query on the routing table).
Figure 15. Header.
Message routing
The routing table is the key element for directing messages in the network. Each gateway is assigned
a unique ID that must be included in the message headers. The routing table (Table 2) contains the
BGW-Id, and maps out all the possible paths in the network.
To simplify the routing process, a list of reachable BGWs is created. For each linked BGW, the
routing table contains a “next node” that specifies the destination BGW to which the message must
be sent to ensure successful delivery. The “next node” BGW then repeats the process and sends the
message to the next node in the path until it reaches its destination.
Table 2. Routing table
Source Gateway
Destination Gateway
Next node
In the table above the rows with no information in the column “Next node” refer to direct links,
and the others refer to indirect links. This corresponds to the following network:
Figure 16. Network topology described the routing table reported in Table 2.
The routing table is replicated in every gateway. Figure 16 is a graphical representation of the
Border Gateway Network (BG Network) topology described in the routing table in Table 2. The network topology can be changed, as a new BGW or link is added (or removed) and the corresponding
routing tables will need to be updated.
The business relationship between IPSs must be known to the network nodes, and for this
purpose a table called the Business Relationship Table is kept up-to-date. An example of this
table is shown in Table 3 in the simple case where only I P S X and I P S X have created a business
relationship for instant payment and lookup services.
Table 3. Business relationship table
Source IPS
Destination IPS
Service type
I P SX
I P SY
Payments+Lookup
I P SY
I P SX
Payments+Lookup
Here are two examples of network configurations. The first one is for a single bilateral extended
link between IPSs A and B. They have established a bilateral relationship for executing instant
payments through an FX service. In the BGWs’ network, there is also a redundancy of connections.
This allows for the possibility of having two paths for routing payment messages. Figure 17 and
Table 4 display the network topology and the corresponding routing and business tables.
Figure 17. Example 1 – one inderect link with redundant path.
Table 4. Example 1 – Routing and Business relationship tables for example reported in Figure
(a) Routing table
(b) Business relationships table
Source Gw
Destination Gw
Next node
Source IPS
Destination IPS
Service type
I P SA
I P SB
I P SB
I P SA
Payments+Lookup
Payments+Lookup
The routing table’s first two rows show two possible paths (highlighted in blue and red in Figure
17) for individual payment messages to reach actors A and B in a business transaction. The BGWA
chooses the logic for using these paths, which can either be load distribution or failover logic. When
there are many paths, the sending Gateway needs to choose which path to use. For this purpose, a
Gateway may assign a priority26 to the available paths and try to follow the first available27 path in
priority descending order.
It’s worth noting that the table of business relationships remains unchanged regardless of the
26. As an example, the priority might be assigned considering the fees that each Gateway in each path applies.
27. The concept of “available path” is local to the Gateway and it is dynamic: when a given number of messages sent to
the path are timed-out, the Gateway assumes that the path is not operational anymore. The Gateway tries to send messages
through that path only after a special “dummy” message has revealed that the path works.
message routing logic used. In this example, jurisdiction A is connected to jurisdiction B in different
ways via jurisdiction Z in the case of the blue path, and via jurisdictions X and Z in the case of the
red path. In both scenarios, the BGWs of jurisdictions X and Z only perform the message routing
functions.
The second example involves connecting IPS pairs A-B and A-C through two separate FX services
and the same BWG network as in the previous example. The network topology and routing tables
for this second scenario are shown in Figure 18 and Table 5.
Figure 18. Example 2 – two indirect links.
Table 5. Example 2 -Routing and Business relationship tables
(b) Business relationships table
(a) Routing table
Source Gw
Destination Gw
Next node
Source IPS
Destination IPS
Service type
I P SA
I P SA
I P SB
I P SC
I P SB
I P SC
I P SA
I P SA
Payments+Lookup
Payments+Lookup
Payments+Lookup
Payments+Lookup
The message routing table remains unchanged, except for the redundant link being removed,
while the business relationship table expands to account for the two extended links. It’s worth
noting that the same direct link between BGWA and BGWX is used to carry messages from both
business services of the I P S A -I P S B and I P S A -I P S C pairs.
Network topology
As of today, more than 75(BIS 2024) settlement systems are active for instant payments (IPS).(BIS
2023b) Connecting all these systems with direct bilateral links would result in about 1,700 links
(see Figure 19). With the introduction of the indirect bilateral links described above, the maximum
number of indirect links needed to connect all IPSs active today would be significantly reduced to
a minimum of 59 links (N l i nk = (n − 1) in the best case).
Figure 19. Number of links and number of hops.
It is evident that the use of indirect bilateral links also increases the number of hops required
to reach the target IPS (N hops = n − 1) in the worst case (Figure 19). However, considering that
intermediate IPSs do not perform settlement functions but only message routing functions it can be
assumed that the impact on the end-to-end settlement latency of the single payment is negligible
when compared with the business timeout of instant payments (typically tens of seconds).
The proposed interconnection model enables the creation of different network topologies. Two
relevant examples are shown in Figure 20. One example is a ring topology where each IPS is always
connected to at least two other IPSs, allowing for two possible paths for payment messages and
reducing the maximum number of hops required for a payment. The second relevant topology
is a hierarchical topology in which some IPSs, typically those related to jurisdictions with larger
payment flows, are connected in full-mesh mode, while IPSs from jurisdictions with less traffic are
only connected to IPSs from larger jurisdictions.
Figure 20. Examples of topologies: Ring and Hierarchical
A further step: automatic foreign exchange
A further step to improve the cross-currency interoperability solution would be achieved by including the FX functionality within the perimeter of the interlinked systems (BIS 2025).
Nevertheless, it should be pointed out that the provision of an FX step that is synchronous with
each instant payment poses technical challenges regarding the scalability of the solution. Whatever
the solution is, the selling and buying of the two currencies, as well as the determination of the
exchange rates, must happen within the time of the instant payment transaction(s). Secondly,
the provision of the currencies into the systems, must in any case involve financial institutions,
establishing a logic for their remuneration.
With the above considerations in mind, an “automatic FX” solution may take the form of a
“liquidity pool” created as a centralized service within each of the two interlinked systems. In such
a liquidity pool the two currencies would be pre-founded by liquidity providers, i.e. by the market
actors willing to trade the two currencies.
Figure 21. FX with liquidity pool at the sending IPS.
In Figure 21. the sending system runs an algorithm 28 that automatically determines the exchange rate. This must happen for each and every payment, not compromising the speed and
scalability of the domestic IPS system. The exchange rate and remuneration of liquidity providers
are unavoidably correlated and linked to the stock of each currency, mitigating the risk that the
pool runs out of some currency. Nevertheless, it is essential to ensure that the three processes
needed for (i) determining the exchange rate, (ii) triggering the pre-funds the liquidity, and (iii)
establishing the remuneration of the liquidity providers, are technically independent, i.e. to make
they run in different times, without injecting delays in the instant and payment and/or endangering
its synchronicity.
Adopting a liquidity pool helps keep only (i) within the payment processing duration and keeping
(ii) and (iii) as technically independent and “detached” from the payment processing, the message
protocol for payment interoperability changes as shown in Figure 22. The two Settlement Account
Provider in the previous scheme shown in Figure 11, may still be present but they have been
dropped in this option as they are not strictly needed anymore when FX is provided by the IPS. In
the above scheme, the assumption is that FX is carried on into the sending IPS, but, at the same
time, the other way round would work as well29
Figure 22. Cross-currency payment flow with liquidity pool at the sending IPS.
To implement the liquidity pool, the I P S A must have in its balances the two accounts corresponding to old the two currencies to be used in the settlement of the payments. These accounts
have a different nature with respect to the participants’ accounts as they belong to the balance
sheet activities and are charged/credited for each incoming or outgoing payment, as well as by the
bidirectional liquidity transfer operations entered, independently and in different moments, by the
liquidity providers.
28. This algorithm may be either purely internal, i.e., determining the exchange rate depending on the quantities of
exchanged currencies in dedicated “pools” (for further information, please refer to the definition of Automated Market
Makers (BIS 2023a)). A further possibility is also relying upon an external price “oracle”, i.e. on external service providing the
current exchange rate for a given currency pair. For the sake of this discussion, it is relevant to consider the exchange rate
determination as a task carried out externally to the payment systems
29. I.e. the payment is sent out by I P S A still denominated in currency A and I P S B, shortly before settling it, takes care of
converting ts amount into currency B
Account view
Adopt a liquidity pool automatic FX function, the booking on accounts held in I P S A and
I P S B are shown hereafter: the number (n:) refers to the step, listed in the flow described in
Fig.22, where the booking takes place, x and y are the sent and received amounts, A is the
currency of the amount x and B is the currency of the amount y . In the I P S A two accounts
are open to hold the currencies A and B, supposed to be the domestic and the foreign.
The pre-funded holdings of the foreign currency (B) are deposited in LPA by the liquidity
providers, while the corresponding value of the foreign currency (B), sold to P S P A, is
deposited in the pool LP A . Supposing to use the liquidity pool only for outgoing payments
(from A to B), then LP B would always be debited and LPA would always be credited. In a
more efficient set-up, nevertheless, the same liquidity pool would serve both outgoing and
incoming payments, thus potentially reducing the need for rebalancing.
I P S A ledger
P S PA
(1:) -x A (reserved)
I P S B ledger
LPA LPB
P S PB
(1:) +x A -y B
(6:) -y B
(6:) +y B
(7b:) -x A (settled)
(7ba 🙂 -x A +y B
a. Negative result from I P S B . This reverses the bookings registered with step (1:).
b. This is a mirror account of LPB in I S PA if I P S B is the only IPS connected to I P S A and settling currency B. If
not, this is a vostro account of an account relationship between the two IPSs
Conclusions
The number and volume of “Fast payments” or “Instant payments” solutions are rapidly increasing.
By linking these systems together, we can facilitate cross-border and cross-currency payments
quickly and efficiently. This development will enhance the user experience, allowing for synchronous payments where the payer is informed within seconds whether the funds have been received
or not, extending from domestic to international scenarios.
This paper proposes a technical solution built on two main pillars: (i) defining an “interoperability protocol” that outlines the sequence of events and messages needed to synchronize payments
settled in different systems, and (ii) identifying rules for reusing network links to simplify the complexities associated with connecting different Instant Payment Systems (IPSs) through multiple
bilateral links.
The proposed model introduces a multi-authority framework for cross-border instant payments
that respects the regulatory sovereignty of each jurisdiction. National Instant Payment Systems
(IPSs) retain full control over AML/CFT enforcement and tax compliance, applying their own rules
to both domestic and international transactions without delegating oversight to a central body.
In essence, the model offers a decentralized yet interoperable infrastructure for cross-border
instant payments. It enables technical coordination without compromising national regulatory
autonomy. A baseline level of coordination among jurisdictions—particularly on security and
compliance procedures—is necessary to ensure operational effectiveness and trust.
We believe that the architecture of centralized platforms is the most efficient and that its emergence in the future is desirable for creating an integrated network and a harmonized global system.
This calls for supranational initiatives that foster collaboration among national organizations.
In the meantime, while waiting for multilateral platforms to develop, we can rely on bilateral
connections. By investing in and enhancing these connections, we can maximize their marginal
utility. We recognize that this proposed model introduces additional overhead to the implementation of the initial bilateral link. This arises from the need to achieve minimum harmonization
required by the interoperability protocol and to establish the mechanisms for reusing bilateral links
from the outset. However, this initial burden represents an investment that will help the network of
bilateral connections evolve towards the efficiency of a centralized system without ruling out the
possibility of adopting such a model in the future. This strategy simplifies governance compared to
hub-and-spoke and centralized models, as it eliminates the need for managing operational phases
and only requires regulation of the technical protocols for interlinking IPSs. Furthermore, this
interconnection model preserves the autonomy of each jurisdiction regarding Anti-Money Laundering (AML) and Combating the Financing of Terrorism (CFT) policies, allowing each jurisdiction to
independently establish its transit rules through its IPS system.
According to our model, the interconnected network of payment systems can gradually expand
to include an increasing number of IPSs, similar to the development of the Internet in its early
stage, where a minimal set of harmonization rules is defined while leaving ample room for network
expansion.
References
Bindseil, U. and G. Pantelopoulos. 2023. “Introduction to Payments and Financial Market Infrastructures”, 64.
https://www.bis.org/publ/othp62.pdf.
BIS. 2023a. “Project Mariana: cross-border exchange of wholesale CBDCs using automated market-makers”,
https://www.bis.org/publ/othp75.htm.
. 2023b. “Project Nexus – Enabling instant cross-border payments”. BIS Innovation Hub, nos. 2023-03,
https://www.bis.org/publ/othp62.pdf.
. 2024. “Regional payment infrastructure integration: insights for interlinking fast payment systems”,
https://www.bis.org/cpmi/publ/brief4.pdf.
. 2025. “Project Rialto – Improving instant cross-border payments using central bank money settlement”,
https://www.bis.org/publ/othp91.pdf.
Boar, C., S. Claessens, A. Kosse, R. Leckow and T. Rice. 2021. “Interoperability between payment systems
across borders”, https://www.bis.org/publ/othp62.pdf.
Butijn, B.-J., D. A. Tamburri and W.-J. van den Heuvel. 2020. “Blockchains: A Systematic Multivocal Literature
CPMI. 2016. “Correspondent banking”, http://www.bis.org/cpmi/publ/d147.pdf.
. 2023. “Exploring multilateral platforms for cross-border payments”. BIS, https://www.bis.org/cpmi/
publ/d213.pdf.
ECB. n.d. “Reporting in the case of nostro/vostro accounts”, https://www.ecb.europa.eu/stats/ecb_statistics/
anacredit/questions/html/ecb.anaq.180124.0014.en.html.
Ghiro, L., F. Rinaldi, G. Dini, S. Basagni, A. Montresor and M. Conti. 2021. “What is a Blockchain? A Definition to
Clarify the Role of the Blockchain in the Internet of Things”. In Proceedings of the 2021 IEEE International
Conference on Communications Workshops (ICC Workshops), 1–6. IEEE. https : / / doi . org / 10 . 1109 /
IOSCO. 2012. “Principles for financial market infrastructures”, 149. http://www.bis.org/cpmi/publ/d101a.pdf.
Renzetti, M., A. Dimartina, R. Mancini, G. Sabelli, F. Di Stasio, C. Palmers, A. F. et al. 2022. “Cross-Currency
Settlement of Instant Payments in a Cross-Platform Context: a Proof of Concept”. Markets, Infrastructures,
Payment Systems, nos. 2022-19, https://www.bancaditalia.it/pubblicazioni/mercati-infrastrutture-esistemi-di-pagamento/approfondimenti/2022-019/N.19-MISP.pdf.
Recently published papers in the ‘Markets, Infrastructures, Payment Systems’ series
n. 31
Open Banking in the payment system: infrastructural evolution, innovation and security,
supervisory and oversight practices, by Roberto Pellitteri, Ravenio Parrini, Carlo Cafarotti
and Benedetto Andrea De Vendictis (Institutional Issues) (in Italian)
n. 32
Banks’ liquidity transformation rate: determinants and impact on lending, by Raffaele Lenzi,
Stefano Nobili, Filippo Perazzoli and Rosario Romeo (Research Papers)
n. 33
Investor behavior under market stress: evidence from the Italian sovereign bond market, by
Onofrio Panzarino (Research Papers)
n. 34
Siamese neural networks for detecting banknote printing defects, by Katia Boria, Andrea
Luciani, Sabina Marchetti and Marco Viticoli (Research Papers) (in Italian)
n. 35
Quantum safe payment systems, by Elena Bucciol and Pietro Tiberi
n. 36
Investigating the determinants of corporate bond credit spreads in the euro area, by Simone
Letta and Pasquale Mirante
n. 37
Smart Derivative Contracts in DatalogMTL, by Andrea Colombo, Luigi Bellomarini, Stefano
Ceri and Eleonora Laurenza
n. 38
Making it through the (crypto) winter: facts, figures and policy issues, by Guerino Ardizzi,
Marco Bevilacqua, Emanuela Cerrato and Alberto Di Iorio
n. 39
The Emissions Trading System of the European Union (EU ETS), by Mauro Bufano, Fabio
Capasso, Johnny Di Giampaolo and Nicola Pellegrini (in Italian)
n. 40
Banknote migration and the estimation of circulation in euro area countries: the italian
case, by Claudio Doria, Gianluca Maddaloni, Giuseppina Marocchi, Ferdinando Sasso,
Luca Serrai and Simonetta Zappa (in Italian)
n. 41
Assessing credit risk sensitivity to climate and energy shocks, by Stefano Di Virgilio, Ivan
Faiella, Alessandro Mistretta and Simone Narizzano
n. 42
Report on the payment attitudes of consumers in Italy: results from the ECB SPACE 2022
survey, by Gabriele Coletti, Alberto Di Iorio, Emanuele Pimpini and Giorgia Rocco
n. 43
A service architecture for an enhanced Cyber Threat Intelligence capability and its value
for the cyber resilience of Financial Market Infrastructures, by Giuseppe Amato, Simone
Ciccarone, Pasquale Digregorio and Giuseppe Natalucci
n. 44
Fine-tuning large language models for financial markets via ontological reasoning,
by Teodoro Baldazzi, Luigi Bellomarini, Stefano Ceri, Andrea Colombo, Andrea Gentili
and Emanuel Sallinger
n. 45
Sustainability at shareholder meetings in France, Germany and Italy, by Tiziana De Stefano,
Giuseppe Buscemi and Marco Fanari (in Italian)
n. 46
Money market rate stabilization systems over the last 20 years: the role of the minimum
reserve requirement, by Patrizia Ceccacci, Barbara Mazzetta, Stefano Nobili, Filippo
Perazzoli and Mattia Persico
n. 47
Technology providers in the payment sector: market and regulatory developments,
by Emanuela Cerrato, Enrica Detto, Daniele Natalizi, Federico Semorile and Fabio Zuffranieri
n. 48
The fundamental role of the repo market and central clearing, by Cristina Di Luigi, Antonio
Perrella and Alessio Ruggieri
n. 49
From Public to Internal Capital Markets: The Effects of Affiliated IPOs on Group Firms,
by Luana Zaccaria, Simone Narizzano, Francesco Savino and Antonio Scalia
n. 50
Byzantine Fault Tolerant consensus with confidential quorum certificate for a Central Bank
DLT, by Marco Benedetti, Francesco De Sclavis, Marco Favorito, Giuseppe Galano, Sara
Giammusso, Antonio Muci and Matteo Nardelli
n. 51
Environmental data and scores: lost in translation, by Enrico Bernardini, Marco Fanari,
Enrico Foscolo and Francesco Ruggiero
n. 52
How important are ESG factors for banks’ cost of debt? An empirical investigation,
by Stefano Nobili, Mattia Persico and Rosario Romeo
n. 53
The Bank of Italy’s statistical model for the credit assessment of non-financial firms,
by Simone Narizzano, Marco Orlandi and Antonio Scalia
n. 54
The revision of PSD2 and the interplay with MiCAR in the rules governing payment services:
evolution or revolution?, by Mattia Suardi
n. 55
Rating the Raters. A Central Bank Perspective, by Francesco Columba, Federica Orsini and
Stefano Tranquillo
n. 56
A general framework to assess the smooth implementation of monetary policy:
an application to the introduction of the digital euro, by Annalisa De Nicola and Michelina
Lo Russo
n. 57
The German and Italian Government Bond Markets: The Role of Banks versus Non-Banks.
A joint study by Banca d’Italia and Bundesbank, by Puriya Abbassi, Michele Leonardo
Bianchi, Daniela Della Gatta, Raffaele Gallo, Hanna Gohlke, Daniel Krause, Arianna
Miglietta, Luca Moller, Jens Orben, Onofrio Panzarino, Dario Ruzzi, Willy Scherrieble and
Michael Schmidt
n. 58
Chat Bankman-Fried? An Exploration of LLM Alignment in Finance, by Claudia Biancotti,
Carolina Camassa, Andrea Coletta, Oliver Giudice and Aldo Glielmo
n. 59
Modelling transition risk-adjusted probability of default, by Manuel Cugliari, Alessandra
Iannamorelli and Federica Vassalli
n. 60
The use of Banca d’Italia’s credit assessment system for Italian non-financial firms within
the Eurosystem’s collateral framework, by Stefano Di Virgilio, Alessandra Iannamorelli,
Francesco Monterisi and Simone Narizzano
n. 61
Fintech Classification Methodology, by Alessandro Lentini, Daniela Elena Munteanu and
Fabrizio Zennaro
n. 62
The Rise of Climate Risks: Evidence from Expected Default Frequencies for Firms, by Matilde
Faralli and Francesco Ruggiero
n. 63
Exploratory survey of the Italian market for cybersecurity testing services, by Anna Barcheri,
Luca Bastianelli, Tommaso Curcio, Luca De Angelis, Paolo De Joannon, Gianluca Ralli and
Diego Ruggeri
n. 64
A practical implementation of a quantum-safe PKI in a payment systems environment,
by Luca Buccella and Stefano Massi
n. 65
Stewardship Policies. A Survey of the Main Issues, by Marco Fanari, Enrico Bernardini,
Elisabetta Cecchet, Francesco Columba, Johnny Di Giampaolo, Gabriele Fraboni, Donatella
La Licata, Simone Letta, Gianluca Mango and Roberta Occhilupo
n. 66
Is there an equity greenium in the euro area?, by Marco Fanari, Marianna Caccavaio, Davide
Di Zio, Simone Letta and Ciriaco Milano
n. 67
Open Banking in Italy: A Comprehensive Report, by Carlo Cafarotti and Ravenio Parrini
n. 68
Report on the payment attitudes of consumers in Italy: results from ECB SPACE 2024 survey,
by Gabriele Coletti, Marialucia Longo, Laura Painelli, Emanuele Pimpini and Giorgia Rocco