1. Executive summary
Nexus, a BIS Innovation Hub (BISIH) project, explores how to build on the success of domestic instant payments to improve the speed, cost, transparency and accessibility of cross-border payments.
Cross-border payments are often slow, offering a frustrating user experience and imposing significant costs on individuals and businesses. In contrast, in over 60 countries today domestic payments reach their destination in seconds at near zero cost to the sender or recipient. This is thanks to the growing availability of instant payment systems (IPS).
Cross-border payments could be significantly improved by linking up domestic IPS in multiple countries. In April 2021, Singapore and Thailand connected their IPS, allowing customers of participating financial institutions to send payments across the border using just the recipient’s phone number. This was followed in February 2023 by an IPS link between Singapore and India. Several initiatives in the Southeast Asian region and globally aim to do the same, through bilateral links.
However, connecting countries one-to-one soon becomes complex, since every IPS has different technical standards, business processes and regulatory requirements. Each new bilateral initiative requires a complex technical integration and multi-party legal negotiation.
Nexus addresses these challenges by making it easier to interlink multiple instant payment systems on a distributed network through a standardised and multilateral approach. Each IPS would need to invest time and resources to be able to connect to and communicate with Nexus, but this would be a one-time effort rather than being repeated every time they connect to a new country.
In 2021, the BIS Innovation Hub (BISIH) Singapore Centre developed and published a blueprint for a service to connect instant payment systems across borders.4 In 2022, the team built a working prototype of Nexus, based on this blueprint and used it to connect the test systems5 of three established IPS:
The Eurosystem’s TARGET Instant Payment Settlement (TIPS) system, operated by Banca d’Italia on behalf of the Eurosystem and overseen by the European Central Bank;
Malaysia’s Real-time Retail Payments Platform (RPP) operated by Payments Network Malaysia (PayNet) and overseen by Bank Negara Malaysia; and
Singapore’s Fast and Secure Transfers (FAST) payment system, operated by Banking Computer Services (BCS) and overseen by the Monetary Authority of Singapore.
Nexus is designed with a strong focus on usability and user experience. For example, where proxies – such as a mobile phone number – can be used to address domestic payments, Nexus allows these proxies to be used for cross-border payments too. This means that payers do not have to enter long international bank account numbers (IBANs) or unfamiliar local account details. To enable proxies in the proof of concept, the team connected the following proxy (or “alias”) resolution services (in addition to the core payment systems):
- TIPS’s Mobile Proxy Lookup (MPL) service
- Malaysia’s DuitNow, and
- Singapore’s PayNow
A range of design workshops with more than 50 parties, including central banks, payment system operators, commercial banks and payment service providers (PSPs) and foreign exchange providers (FXPs) helped to identify the kind of data exchange and functionality that a Nexus arrangement would need to support.
The proof of concept has resulted in three detailed outputs, which could help IPS operators to speed up the process of connecting to one another:
A detailed technical framework, including API specifications, ISO 20022 message guidelines and business processes, which could be followed when connecting IPS;
A detailed Nexus scheme rulebook, which covers the cross-border aspects of payments that are not covered by domestic IPS schemes and defines the obligations and responsibilities of Nexus participants; and
Working software, built entirely on open-source components, to connect IPS and enable cross-border proxy resolution (eg mapping a mobile phone number to an account) and instant payments.
The key lessons from this experience are summarised in Chapter 10.
This report is accompanied by detailed technical documentation available at docs.bis.org/nexus, which includes guides for each type of participant in Nexus. The framework is comprehensive but not final and feedback is welcome. IPS operators following the technical framework to connect to others are likely to save months of design work. It should also serve as a useful reference for IPS operators looking to future-proof their systems for more efficient cross-border payments.
The key obligations and rules from the Nexus Scheme Rulebook are summarised at the accompanying site, docs.bis.org/nexus, but the full scheme rulebook will be further developed during the next phase of the work.
The software developed can facilitate cross-border proxy resolution, instant cross- border payments and the management of foreign exchange quotes across multiple IPS. However, as it has not been developed to “production grade”, it would require further work on security, resilience, performance and functionality before it would be ready to process live payments. For this reason, the codebase is not available for open release.
Lessons learnt
The Nexus proof of concept demonstrates that connecting IPS multilaterally is technically feasible and could have significant potential benefits for individuals and businesses across the world.
The project had to tackle a number of challenges. There are wide differences between the design of different IPS and their proxy schemes, and it is not realistic to expect the industry to move to a single standardised design. Instead, it is important to find ways to accommodate those differences, both through tools that support technical interoperability, such as the ISO 20022 standard for message formats and APIs, as well as through methods to promote business interoperability, such as a cross-border scheme that gives IPS a clear rulebook for their interactions with other IPS.
One of the most challenging frictions in (instant) cross-border payments is sanctions screening. There is often a conflict (real or perceived) between the requirement to screen payers and payees using high-quality verified data, and the restrictions that data protection rules place on sharing these data. Nexus proposes a number of methods to improve this data-sharing, so reducing the amount of manual processing.
These lessons are discussed in detail in Chapter 10.
Next steps
Strong interest in implementing Nexus-type solutions has emerged. In Southeast Asia, the central banks of Indonesia, Malaysia, the Philippines, Singapore and Thailand wish to connect their domestic IPS to enable cross-border payments. These countries are pioneers in building bilateral instant cross-border payments links and now wish to connect all countries multilaterally. These five countries alone have a combined population of 490 million and a GDP of US$ 2.6 trillion, with strong trading and remittance flows.
In the next phase of Nexus, the BISIH Singapore Centre will collaborate with the ASEAN central banks and their payment system operators as they prepare to connect their domestic payment systems, using the Nexus blueprint as the foundation.
The ASEAN central banks share a desire for any real-world implementation of Nexus to be global rather than regional. The BISIH Singapore Centre plans to establish a Global Advisory Panel of central banks and payment system operators from major instant payments markets, who would advise on the development of Nexus beyond the Southeast Asia region.
Payment system operators interested in using or building on the Nexus blueprint can contact the project team at singapore.centre@bisih.org.
Acknowledgements
The BISIH Singapore Centre would like to thank our partners in the proof of concept: Banca d’Italia, Bank Negara Malaysia, Monetary Authority of Singapore, PayNet in Malaysia and BCS in Singapore, and the legal, policy, business and technical teams who contributed to the project’s success.
We also thank the many public and private sector workshop participants for their time, insights and feedback. Of course, the final design and any errors are the responsibility of the project team and no endorsement is implied.
For the proof of concept, Tata Consultancy Services were commissioned to further refine the functional design and lead the technical development of the Nexus software, while In4Pay were commissioned to support the development of a Nexus scheme and governance framework. We are grateful to both teams for their dedication and work throughout the project.
2. The potential for linking instant payment systems
Instant payment systems (IPS) are now operational in over 60 countries, with others in development. Connecting these IPS to each other could enable cross-border payments from sender to recipient within 60 seconds, in most cases.
The G20 has made enhancing cross-border payments a priority. As part of a comprehensive roadmap developed by the Financial Stability Board (FSB) and the Committee on Payments and Market Infrastructures (CPMI), one priority theme is the cross-border interlinking of IPS.
Interlinking is already under way: in April 2021, Singapore’s PayNow and Thailand’s PromptPay were linked in a world first, allowing the customers of participating banks in Singapore and Thailand to send money to each other using just the recipient’s mobile phone number.8 This was followed in February 2023 by an IPS link between Singapore and India.9 In Southeast Asia, the central banks of Indonesia, Malaysia, the Philippines, Singapore and Thailand have agreed to connect their domestic IPS to enable cross- border payments.10 In Europe and the United States, EBA Clearing and The Clearing House are collaborating to develop an EUR-USD link. The P27 initiative aims to connect Nordic IPS, while Buna aims to connect IPS in the Arabic-speaking region. In addition, the ECB, Banca d’Italia and Sweden’s Riksbank are exploring the possibility of cross- currency payments between Swedish krona and euros, through the TIPS platform.
Each of these links between IPS can deliver significant benefits for payment service users (individuals and micro, small or medium-sized businesses). However, each bilateral link is a complex project. Cross-border payments require additional steps such as currency conversion and compliance checks to prevent money laundering, the financing of terrorism and other illicit activities. A further challenge comes from the fact that IPS have different technical processes and functionality and often speak different “languages” in the way they share data and payment instructions. Each bilateral link therefore requires complex legal negotiations between payment system operators, central banks, banking associations and individual banks. This investment is only commercially viable when connecting close trading partners or strong remittance corridors, meaning that many lesser-used corridors would never be connected bilaterally.
Another challenge is that the number of bilateral links required grows faster than the number of countries joining the network. A network of five countries requires 10 country-to-country links, but a network of 10 countries would require 45 links,11 each with its own technical integration project and complex legal negotiation.
图3:双边联系的数量增长快于国家数量的增长
Nexus overcomes the limitations of bilateral interlinking by standardising the way that IPS connect. It is a “behind-the-scenes” service that would be used by IPS operators and their member banks or PSPs to route instant cross-border payments. An IPS operator must initially invest resources in terms of time and technology to connect to Nexus but can then connect to every other country on the Nexus network. When a new country joins Nexus, existing members are automatically connected to that country and vice versa. This means the network can expand at near-zero marginal cost for existing members.
Nexus could significantly accelerate the growth of instant cross-border payments. To connect 60 IPS via Nexus would require 60 technical integration projects (one between each IPS and Nexus) compared with 1,770 bilateral initiatives. This reduces the work required by more than 95%. In short, Nexus makes it possible to connect all IPS in a way that would be impractical through bilateral links.
编辑搜图
图4:Nexus网关相互连接IPS，跨越边界
Benefits of interlinking instant payment systems through Nexus
Sending cross-border payments through domestic IPS could make a significant contribution to the FSB’s targets for improving the cost, speed and transparency of cross-border payments, and expanding access to them. 12 To increase the chance that Nexus realises these benefits, the project team set some design principles, as outlined below, to guide the design process.
Speed
As most IPS process domestic payments within 30 seconds, a cross-border payment via Nexus – which would first be processed by the IPS in the sender’s country and then by the IPS in the recipient’s country – could plausibly take 60 seconds or less. In contrast, the speed of traditional cross-border payments via correspondent banking depends on how quickly each bank in a payment chain picks up and processes the payment.
IPS process payments on a 24/7/365 basis (in most cases). In contrast, traditional cross-border payments often rely on central banks’ high-value payment systems, which process transactions between financial institutions and usually operate only during business hours. This means payments can be delayed while waiting for a central bank payment system to “open for business”.13
Design principle: Most Nexus payments should be completed within 60 seconds.
Cost
IPS participants typically pay a small fee per transaction for instant payments. This sets a low-cost base for cross-border payments through IPS – although there are inherently more costs involved in a cross-border payment than in a domestic one (such as sanctions screening, message translation and currency conversion).
Interlinking IPS makes it easier for banks to offer cross-border payments to countries where they have no presence or partnerships. In contrast, traditional cross-border payments often require the bank to hold accounts with a bank in each country that it wants to send payments to, or to route payments through a larger domestic bank (at a cost). These “correspondent” accounts are expensive and time-consuming to set up and many correspondent banks are withdrawing their services.14
Design principle: Nexus should lower barriers to entry to enable a competitive market in FX provision and payment service provision. Nexus should reduce administrative costs (for example, by avoiding manual intervention in sanctions screening.)
Access
Some IPS also provide access to non-bank PSPs. If IPS were interlinked, most citizens could initiate a cross-border payment through their bank or PSP.However, the specific level of access in a country would still depend on the level of financial inclusion and percentage of people who have accounts with banks or PSPs that are connected to IPS in that country.
Another aspect of access is the ease of use, or user experience. IPS are often linked to proxy services that allow payments to be addressed using only the recipient’s mobile phone number, email address, national identification numbers or company registration number (for example).
These services can be used to make addressing a cross-border payment much easier than using (for example) a ~30-character International Bank Account Number (IBAN).
Design principle: Anyone who can send and receive a domestic instant payment through the local IPS should be able to send and receive cross- border payments through Nexus (subject to the necessary compliance checks and assuming their bank or PSP has completed the necessary on-boarding). Senders should be able to use their existing PSP’s app to send payments. Proxies that are valid for domestic payments (eg mobile phone numbers) should also work internationally through Nexus. Payers and payees do not need to (and cannot) interact with Nexus directly.
Transparency
Transparency in traditional cross-border payments services, variable fees are levied by each bank in the payment chain. This means the sender does not know how much the recipient will receive until the payment reaches them. With interlinked IPS, it is possible to calculate fees upfront and show them to the sender before they decide to make a payment.
Traditional cross-border payments may fail at multiple stages in the payment chain, sometimes hours after the sender had initiated the payment. In cases of failure, the sender may not be notified directly, or may find out only when they are told by the intended recipient. In contrast, a payment through an IPS either completes or fails within seconds, by design, so that the sender has transparency and certainty about the status of their payment.
Design principle: Fees and FX rates should always be shown to the sender before they decide to make the payment. The sender should always know exactly how much will be credited to the recipient’s account. The sender should be given the opportunity to confirm that they are sending funds to the correct account, for example by being able to confirm the name associated with the recipient’s account.
Safety, security and resilience
The safety and resilience of payment systems is a key concern for central banks (and indeed the wider economy). The CPMI and the International Organization of Securities Commissions (IOSCO) have set out the Principles for financial market infrastructures (PFMIs) that help to underpin this safety and resilience.15 IPS already have risk management regimes that help to mitigate (or even eliminate) credit and settlement risks within the domestic payment system. A cross-border network of interlinked IPS payments can build on these risk management frameworks to ensure safety and resilience.
Interlinking IPS also reduces the reliance on correspondent banking relationships (where one bank holds funds with a bank in another country), mitigating the cross-border credit risk between financial institutions.16
Design principle: Nexus should reduce the number of entities that need to accept cross-border exposure to other financial institutions. Nexus should rely on domestic IPS settlement arrangements to manage credit and liquidity risks between financial institutions.
3. The user experience when making a payment through Nexus
This chapter describes the experience of the sender of a payment when sending a payment through Nexus.
Who would use Nexus?
Nexus payments can be sent by individuals or businesses who currently use IPS to send domestic payments (so-called “retail” payments). This means it supports the person-to- person (P2P), business-to-person and person-to-business payment use cases.17
Although larger businesses could use Nexus to send payments to suppliers or employees in other countries, most IPS impose a cap on the value of a domestic payment, meaning that Nexus would not be used to send large “wholesale” payments between financial institutions. Nexus itself does not cap the value of a payment that can be made through its service, but would apply the lowest of the two caps of the domestic IPS.18
Nexus currently supports push payments ie payments that are initiated by the sender. It does not currently support pull payments (such as direct debits or request to pay), or payments at the point of sale, although these features could potentially be developed in the future.
Designing around the ideal user experience
Nexus was designed with a focus on the needs and user experience (UX) of both payers and payees. This required thinking carefully about how users would want to send and receive payments and sketching out a mock app, as used in the examples below, to understand the steps they would need to go through.19 This process revealed the functionality and data exchange that Nexus needs to support. However, Nexus itself is a behind-the-scenes service that connects to IPS operators (and in turn, PSPs, SAPs and FXPs). The sender of a payment would interact only with their PSP; there is no Nexus app and users do not (and cannot) register with Nexus. The walkthrough below demonstrates how an individual sender would make a payment through Nexus, using their existing banking or PSP channel (eg an app) and the steps taken by Nexus behind the scenes.
There are two preparation steps before the payment can be set up:
Each IPS provides its reference data to Nexus. The Reference Data Service (RDS) stores each IPS’s functionality and requirements, such as the format of a domestic account number, whether IBANs are accepted and the maximum value that can be sent. Each IPS shares this information with Nexus, either via the Nexus APIs or the administration portal. Nexus will distribute this information across the network.
FX Providers send their current rates to Nexus. The Nexus FX Service stores quotes provided by multiple FX Providers, who compete to offer the best rates at any time.
With this information in place (and updated whenever necessary) the sender can now set up the payment:
The sender logs in to their bank or PSP’s existing app. (There is no separate Nexus app.)
The sender selects the Destination Country.
The sender enters EITHER the amount they wish to send, in their own currency OR the amount they wish the recipient to receive, in the recipient’s currency.
The recipient will receive exactly the amount shown, without deductions. If the Destination PSP charges the recipient any fees for processing the payment, these must be charged as a separate line item.
If the sender accepts the rate, they click “Continue”. If they change either amount, the rate will be refreshed (as larger payments may be eligible for better rates).
Nexus retrieves a list of quotes. The sender’s PSP (Source PSP) will also ask Nexus for available quotes for payments to the Destination Country. Nexus returns a list of quotes from different FXPs. The Source PSP selects the quote and FX Provider that it wishes to use. The Source PSP can also choose to add a markup to the FX rate before it displays the final rate to the sender.
The sender then selects the type of proxy or account details that the recipient has provided to them.
The sender can select a proxy (such as a mobile phone number). Any alias that is valid in the Destination Country will also be valid through Nexus.
The sender can alternatively enter a domestic account number and PSP identifier (such as a BIC) or an International Bank Account Number, where these are accepted in the Destination Country.
The Source PSP uses the Nexus API to request the full list of proxy formats that can be used to address payments to the Destination Country. It uses this information to dynamically create a list of proxy formats in the app.
If a sender enters a proxy, the Source PSP will send this information to Nexus. Nexus will then contact the proxy resolution service in the Destination Country. If the proxy is registered to an account, it will respond to Nexus with the associated account details and the name of the recipient, along with a display name that can be shown to the sender.
Nexus will then use the account details to confirm that the recipient’s PSP is onboarded with Nexus and able to receive cross-border payments.
Now the sender is shown the name of the recipient, as provided by the proxy resolution service, where available.
Depending on the country’s requirements, they may see the full name or the name partially obscured.
The sender confirms the name. (If they don’t recognise the name, they can cancel the payment).
The sender is given a chance to confirm all details. They are shown exactly what will be deducted from their account, exactly what will be credited to the recipient, the final exchange rate that applies and any fees that the sender’s PSP or bank will charge the sender.The sender clicks “Send Payment”.
Final payment instruction – the payment instruction can now be sent from the Source PSP to the Source IPS.
Once the payment is complete in the Source IPS, the Nexus Gateway will communicate with the Nexus Gateway in the Destination Country, which will trigger the second stage of the process in the destination IPS.
The payment should be processed within 60 seconds in most cases.
Once the final payment stage is complete, the recipient will be credited and notified, and the sender will be notified that their payment was successful.
In some cases, the payment will trigger an alert against any sanctions lists. If the PSP in question does not have a highly automated screening process, it may need extra time to process the payment. In this case, the payment will still successfully reach the recipient’s PSP, but the PSP will have extra time (defined in the Nexus Scheme Rulebook) to review the payment before crediting it to the recipient.
4. The Nexus proof of concept
Based on the blueprint published in 2021, the project team built a working prototype of the Nexus Gateway and used it to connect the test systems of three established IPS:
The Eurosystem’s TARGET Instant Payment Settlement (TIPS) system, operated by Banca d’Italia on behalf of the Eurosystem and overseen by the European Central Bank;
Malaysia’s Real-time Retail Payments Platform (RPP) operated by PayNet and overseen by Bank Negara Malaysia; and
Singapore’s Fast and Secure Transfers (FAST) payment system, operated by BCS and overseen by the Monetary Authority of Singapore
Collectively, over 200 banks are connected to these IPS.
To enable the use of proxies (such as mobile phone numbers) in the proof of concept, each IPS Operator also created replicas of the following proxy resolution services:
TIPS’s Mobile Proxy Lookup (MPL) service
Malaysia’s DuitNow; and
Singapore’s PayNow
Each of these payment systems is important to the functioning of their respective economies. As a rule, since experimental changes should never be made directly on the live or “production” version of a system, the Nexus proof of concept did not connect to these live payment systems or process “real money” payments. Instead, each IPS operator set up an exact replica of its domestic payment system and filled it with manually generated testing data.
The three systems were connected by Nexus Gateways, which managed the communication between each IPS and other IPS on the network. Three instances of the Nexus Gateway were set up in the BISIH’s cloud environment – one per IPS operator (hence, a Singapore Gateway, a Malaysia Gateway and a TIPS Gateway).
The BISIH Singapore Centre then set up three instances of the Nexus Gateway, to handle the communication between each IPS and other IPS on the network.
The proof of concept was conducted using an agile approach: adding functionality incrementally, making adaptations as new challenges or complexities are uncovered; and ensuring that the team “ships” a usable working product, even if it is not perfect. The project proceeded through the following steps:
Ensure secure network connectivity between each IPS operator and the BIS Innovation Hub cloud environment.
Set up an API gateway and message queue service, to manage efficient communication between (a) a Nexus Gateway and the IPS and (b) a Nexus Gateway and all the other Nexus Gateways.
Build and populate a reference data service in the Nexus Gateway: this allows each IPS operator to provide the information that Nexus (and PSPs) needs to process cross-border payments to that IPS, such as the maximum value of a payment allowed in that IPS.
Build an administration portal to make it easier for IPS operators to configure Nexus with the relevant reference data. The individual services in Nexus then distribute this information across the network.
Build and test a cross-border proxy resolution service, which would allow, for example, a payer in Italy to make a payment to Singapore using just the Singaporean mobile number of the recipient. This service connected to proxy resolution services in each country.
In parallel, the partner IPS operators set up testing replicas of their proxy resolution services and configured them to accept proxy resolution requests from Nexus. For the most part, this did not require internal changes to the proxy resolution service but did require some translation between the Nexus-format messages and the domestic format.
Build and test the payment service in the Nexus Gateway. This service allowed payment instructions to be initiated in one IPS, routed through Nexus and processed in the second IPS, before the payment confirmation (or rejection) is sent in the opposite direction.
In parallel, the partner IPS operators set up testing replicas of their payment services and adapted them to process Nexus payments. This required some changes to the specific processing flow, to send payment instructions to the Nexus Gateway rather than simply to another PSP in the same country. Some translation was needed between the domestic format message and the Nexus standard format.
Build an FX service that can accept rates from FX Providers and provide these to PSPs at the point they initiate a payment.
Add additional functionality, such as testing services.
End-to-end testing for an example payment, starting with a proxy resolution request and flowing through each step right through to the successful confirmation of the payment. This testing was conducted between each pair of countries in both directions (eg Italy to Singapore, Italy to Malaysia, Malaysia to Singapore and vice versa for each pair).
In parallel to the technical work, a separate workstream developed a draft scheme and governance framework for the Nexus scheme, to ensure that the technology supported compliance with the necessary rules, obligations, transparency requirements and business processes
Through this process, we:
revealed and addressed several limitations of the original blueprint (such as an inability to accommodate more than one IPS in specific country or currency area);.
added significantly more detail to the design of Nexus, down to the detailed usage of specific elements/fields in an ISO 20022 payment messages;
identified external barriers to truly instant cross-border payments, such as the limitations of many banks’ sanctions screening processes and the lack of harmonisation around regulatory requirements; and
future-proofed the design to accommodate expansion beyond three IPS, building in flexibility that would allow a wide range of IPS to connect, including where two IPS operate in the same currency area.
5.Key components of Nexus
A real-world implementation of Nexus, capable of processing live payments, would require six key components:
Governing entity: Nexus would need to be managed by a governing and operating entity, known provisionally as the Nexus Scheme Organisation (NSO). The NSO would have two main responsibilities: (1) management and onboarding of the Nexus participants and engagement with key stakeholders and (2) provision (but not necessarily operation) of the Nexus product or service, including the elements described below, and the management of changes or enhancements to Nexus itself. See Chapter 9 for further details.
Scheme: The Nexus Scheme would be a binding agreement and rulebook that defines the types of participant in Nexus (such as PSPs, FX Providers, IPS operators and Settlement Account Providers) and their obligations and responsibilities. It also describes the eligibility requirements and process for joining Nexus. A common rulebook and scheme agreement would avoid the need for hundreds of bilateral negotiations between IPS operators and their member PSPs in each country, as well as ensuring a more consistent user experience and service level for payers and payees. See Chapter 9 for further details.
Technical standard: This would provide a standardised approach to interlinking IPS, including best practice approaches and specifications for open APIs and ISO 20022 payment messages. A common technical standard would enable multiple IPS operators to connect without having to adapt to each other country’s unique approach. See Chapter 8.
Software: Nexus Gateways would manage cross-border communication between IPS operators, managing the processing of Nexus payments between two countries. They would also manage other functions such as cross-border proxy resolution, interaction with FX Providers, calculation and provision of FX quotes and relaying other messages between the sender’s PSP and the recipient’s PSP. See Chapter 8.
Secure network: The IPS in Nexus would need a secure network that allows them to send payment instructions to each other, through the Nexus software. See Chapter 10.
Operations: Any payment system requires an operations team that handles membership applications and fees, onboarding and technical testing of new participants, granting permissions for admin users, maintaining and monitoring of the network, managing dispute resolution and providing technical support. This was outside the scope of the proof of concept but would need to be considered carefully in the next phase of the work.
6.Participants in Nexus
A Nexus payment involves the following participants and related actors:
编辑搜图
Figure 5: Participants in a Nexus payment
End users
End users of Nexus can be individuals or businesses who currently use IPS to send domestic payments (so-called “retail” payments).
The sender is the user who initiates the payment and sending money to the recipient. senders and recipients are not members of the Nexus scheme, but do benefit from some of the protections in the scheme, such as the obligations on the PSPs to be transparent about their fees.
IPS Operators
IPS operators run the instant payment systems that enable senders and recipients to make instant domestic payments, ie between two accounts in the same country. They are direct participants in the Nexus scheme.
Payment Service Providers (PSPs)
The sender and recipient both hold accounts at banks (and in some countries, at non-bank Payment Service Providers). In Nexus, the term “PSPs” is used inclusively to cover both banks and non-bank payment service providers who are eligible to connect to an IPS.
In a Nexus payment, the Source PSP is the sender’s PSP and the Destination PSP is the recipient’s PSP. In most cases, all banks in a country will be directly or indirectly connected to the IPS and able to send and receive payments through it.
PSPs are indirect participants in the Nexus scheme, through an agreement with their IPS operator.
Nexus Gateway(s)
To connect the IPS together, each IPS must install and operate a Nexus Gateway. The Nexus Gateway is software that manages communication between IPS to support proxy resolution, FX quote generation and payment processing between two countries.
Each Gateway connects to its local (domestic) IPS infrastructure on one side and to Nexus Gateways in other countries on the other side.
FX Providers (FXPs)
Every cross-border, cross-currency payment requires an actor who is willing and able to exchange one currency for another. In Nexus, the entity providing this service plays the role of FX Provider (FXP). FXPs would be regulated financial institutions that are willing to accept the Source Currency from the sender and pay out the Destination Currency to the recipient.23 They are direct participants in the Nexus scheme.
FX Providers inform Nexus of the current rates at which they are willing to exchange one currency for another. They compete to offer the best rates for a specific corridor, helping to ensure a competitive market.
If the FX Provider is already a member of the Source and Destination IPS, it can directly receive a payment in the Source Currency from the Source PSP and pay out the Destination Currency to the Destination PSP. However, if it does not have membership of either or both, the FXP will instead need to make use of a Settlement Account Provider, as described below.
Settlement Account Providers (SAPs)
In cases where the FX Provider is not a member of either or both IPS, then it can use accounts that it holds with Settlement Account Providers (SAPs) in the Source or Destination Country. Settlement Account Providers are simply existing IPS members (ie PSPs) that are willing to provide accounts to FX Providers who are not themselves members of that IPS.24
When a Nexus payment is processed and the FXP uses SAPs:
the Source PSP makes a payment to the FXP’s account at the Source SAP via the domestic IPS in the Source Country.
the Destination SAP debits the account it holds for the FX Provider and pays out funds to the Destination PSP via the domestic payments system in the Destination Country.
In the diagram, the FX Provider is shown outside any specific country as for any specific payment it may not be based in the Source Country or in the Destination Country. However, the FX Provider will always have a specified home jurisdiction and must be compliant with the rules and regulations of that country.
The Settlement Account Provider acts as a correspondent bank to the FX Provider (its “respondent”). Banks are becoming less willing to provide correspondent banking services to other banks. In Nexus, it is only (some) FX Providers that rely on a correspondent relationship. PSPs that only send and receive payments through Nexus, without acting as an FX Provider, do not need to maintain accounts or relationships with banks outside the country.
Separation of roles in Nexus
Nexus separates the roles of PSP, FXP and Settlement Account Provider, so that they do not necessarily have to be undertaken by the same financial institution. Nexus is designed to be flexible so that financial institutions can fulfil the roles that make commercial sense to them and rely on specialists (such as FX Providers) for services that they do not want to provide themselves. This approach has significant benefits:
It allows financial institutions to fulfil the roles that make commercial sense to them and rely on specialists (such as FX Providers) for services that they don’t want to provide themselves.
It allows PSPs to send cross-border payments without having to hold multiple currencies in multiple countries (because this role is performed by the FX Provider). This also means the PSP does not necessarily have to hold accounts with PSPs in multiple other countries (which can be expensive to set up and maintain).
The use of SAPs allows an FXP to provide currency conversion to PSPs in a country even if the FXP is not a member of a country’s domestic IPS.
Note that some participants may play multiple roles in one payment. For example, if an FX Provider is a member of both the Source IPS and Destination IPS, it can act as Settlement Account Provider to itself. Likewise, the Source PSP may act as FX Provider for its own payments, using funds it holds with a Settlement Account Provider in the Destination IPS.
Each role comes with its own set of obligations and responsibilities, which would be defined in the Nexus Scheme Rulebook (see Chapter 8).
7. How payments are processed through Nexus
Unlike an IPS, Nexus does not maintain a ledger of balances or obligations between financial institutions and PSPs do not hold funds or accounts with Nexus itself. Instead, Nexus acts as the coordinator of two separate but related instant payments across two separate IPS. These two separate payments are processed by the IPS in almost25 the same way as any other domestic payment.
Importantly, Nexus does not require changes to the domestic settlement process in each IPS. The domestic IPS does not need to be aware of any non-domestic currency involved in the payment and does not need to coordinate the timing of their settlement cycles with other countries. IPS that use real-time immediate settlement models,26 or deferred net settlement (DNS) models,27 are fully compatible with Nexus. That said, the IPS will need to make some technical changes to enable the processing of Nexus payments; these changes are described in detail at docs.bis.org/nexus.
Once the sender has completed the setup process shown in Chapter 3 and clicked “Send Payment”, the Source PSP can initiate the final payment instruction. (Note that the following description is simplified, with some steps, such as sanctions screening, left out. A more detailed and technical description of each step is given in the Payment Processing section of the technical docs at docs.bis.org/nexus.)
A worked example
编辑搜图
Figure 6: How a Nexus payment is processed
Once the sender approves the payment:
The Source PSP deducts EUR 100 from the sender’s account.
The Source PSP sends the payment instruction to the Source IPS.
The Source IPS transfers EUR 100 from the Source PSP’s account to the FX Provider’s account (at its Source Settlement Account Provider).
The Source IPS forwards the payment instruction to the Source Nexus Gateway.
The Source Gateway looks up the quote referenced in the payment instruction, applies the currency conversion (so that the value is now SGD 150) and then sends the payment instruction to the Destination Nexus Gateway.
The Destination Gateway forwards the payment instruction to the Destination IPS.
The Destination IPS sends the payment instruction to the FX Provider’s Settlement Account Provider for review.
The Destination Settlement Account Provider checks the FXP has sufficient funds and then sends the payment instruction back to the Destination IPS as an instruction to make the payment to the Destination PSP.
The Destination IPS forwards the payment instruction to the Destination PSP for their review and acceptance.
The Destination PSP reviews the instruction. If it is happy to accept the payment, it will send a confirmation of acceptance back to the Destination IPS.
The IPS transfers SGD 150 from the FXP’s account at the Destination Settlement Account Provider to the Destination PSP.
The Destination PSP credits the recipient.
Finally, the Destination PSP sends a confirmation message (not shown), which flows back through Nexus to the Source PSP, who informs the sender that the payment is complete.
Managing risk in Nexus
Nexus is designed to build on the strong and robust risk management capabilities already present within domestic IPS schemes.
Most IPS schemes have measures to mitigate credit risk and settlement risk within the domestic payment system. Deferred Net Settlement schemes may use pre-funding and collateral arrangements, whereas RTGS systems use immediate settlement in central bank money. Nexus builds on this risk management to avoid creating credit and settlement risk between PSPs in different countries (see docs.bis.org).
For FX Providers, FX risk in Nexus is relatively limited because the time between a rate being provided and the payment being completed is no more than a few minutes.
However, FX Providers who use Settlement Account Providers will have cross-border exposures to those SAPs.
These risks must be managed bilaterally between these parties, but do not in any case pose a risk to the immediate processing of Nexus payments.
The Destination Settlement Account Provider, who must pay out funds to the Destination PSP, also faces some liquidity risk. This is because it does not control the rates offered by the FX Provider and therefore cannot control the demands on the liquidity it holds at the Destination IPS. However, this risk can be managed via an agreement and communication between the FX Provider and Destination Settlement Account Provider.
8. The Nexus network and Nexus Gateways
This chapter explains the main functionality and services provided by Nexus through the Nexus Gateways. For a technical description of the Nexus Gateways built during the proof of concept, see the Annex.
Distributed network
Nexus uses a distributed network model, with no central hub. Each IPS would install and run a software application called the Nexus Gateway. Each Gateway would communicate with Nexus Gateways in other countries to support the key functions required to make a cross-border payment. When information is submitted to one Gateway (for example, if a new PSP joins Nexus in Singapore), this will be distributed across the network as appropriate, so that data are stored where needed (see Figure 7, steps 1 & 2).
Importantly, the distributed model means that data relating to payments only travel through
– and are stored in – the two countries where they belong (see Figure 7, steps 3 and 4).
编辑搜图
Figure 7: Data flows through Nexus
Messaging via ISO 20022
Nexus uses the ISO 20022 standard for data messages when sending cross-border payment messages, with specific usage guidelines for Nexus payments.
Different payment systems and bank systems use different data formats, meaning the data in a payment message can be corrupted or truncated as they are converted from one format to another. Some local message formats do not allow enough space to carry the additional information required for cross-border payments. Inaccurate or incomplete data can cause problems with processing and increase the number of false alerts resulting from sanctions screening, adding costs and delay.
The ISO 20022 standard for data messages provides a better structure and more space for payments-related data.28 It is being adopted across a range of payment systems, including the SWIFT cross-border network, and is already used by many domestic IPS.
The Nexus Gateways expect to receive messages in the ISO 20022 format, correctly structured for Nexus. Where a domestic IPS does not use ISO 20022 – or where it uses an ISO 20022 customisation different from the one specified in the Nexus usage guidelines – the IPS will be responsible for translating the message in order to comply with the Nexus ISO 20022 specifications (and for translating from that format to the domestic format for the return message).
Reference data service
The Reference Data Service (RDS) contains the essential information that is required to make Nexus work, such as:
The instant payment systems available in each country and the currencies that each IPS operates in. Most IPS operate only in a single currency, but others may provide multiple currencies, such as Hong Kong SAR (HKD, CNH) and TIPS (EUR, SEK).
For each IPS:
º The PSPs onboarded with that IPS
º The maximum value of a payment that can be made in that IPS (in the domestic currency)
º Whether International Bank Account Numbers (IBAN) can be used to address payments
º The format of local account numbers and financial institution identifiers (if any)
º Any mandatory data elements that must be included on payments sent to that country – for example, some countries require a purpose code to be set for each payment
Some of this information is used by PSPs sending payments through Nexus and some is used internally by Nexus to understand how to process payments to specific countries.
Proxy service
The proxy service:
provides Source PSPs with a list of the proxy schemes available for each country (eg MPL for TIPS, DuitNow for Malaysia, PayNow for Singapore), along with each proxy format provided by that scheme (eg mobile phone, email, corporate identity number).
º This allows the Source PSP to ask the sender for any proxy that is valid in the destination country.
Accepts proxy resolution requests from Source PSPs and forwards these requests to the relevant proxy scheme. If the given proxy is registered and linked to an account, the proxy scheme will send this information to Nexus, which will forward it to the Source PSP.
编辑搜图
Figure 8: Flow of a proxy resolution request through Nexus
Payment service
The payment service manages all payment-related messages between the source and destination country. Specifically:
It accepts payment instruction (in the form of ISO 20022 pacs.008 messages) from the Source IPS, validates them, transforms29 them and forwards them to the Destination IPS.
It accepts payment confirmation messages (in the form of ISO 20022 pacs.002) from the Destination IPS, validates and transforms them and forwards them to the Source IPS.
The project team designed payment messages for two additional important features but, due to time constraints, was not able to configure the Nexus Gateway to support them:
Nexus would process payment status investigations (in the form of ISO 20022 pacs.028 messages) and relay the response from the Destination PSP back to the Source PSP.
Nexus would process requests by a Source PSP to have an earlier payment returned (in the form of camt.056), the response to that message (camt.029 – with an acceptance or rejection of the request) and the actual payment return instruction (pacs.004)
FX Service
The FX Service is responsible for:
Accepting the following information from FX Providers and distributing it across the network to where the information will be used (Figure 9, step 1 and 2):
º Their current rates on each corridor (currency pair) for which they provide FX.
º Whether larger payments qualify for better rates, the thresholds at which those better rates apply and the improvement (in basis points) to apply to that rate.
º Whether specific PSPs (eg preferred customers of an FXP) qualify for better rates and if so, the exact improvement (in basis points) that should be applied to those rates.
Accepting quote requests from PSPs (Figure 9, step 3), retrieving the rates provided by FXPs and applying any relevant improvements (based on the size of the transaction or the PSP that is making the request), then returning specific quotes to the Source PSP (Figure 9, step 4).
Providing the Source PSP with the FXP accounts (“intermediary agents” in ISO 20022 terminology) which need to be referenced in the pacs.008 payment instruction, so that funds can be credited to the FXP’s account in the Source IPS and debited from the FXP’s account in the Destination IPS.
编辑搜图
图9:外汇服务从外汇提供商获取报价，并与psp共享
Request for Information (RFI) service
In Nexus, the Source PSP, Destination PSP and Settlement Account Providers must screen the sender and recipient against the sanctions lists applicable in their jurisdiction to check that neither party is on the sanctions list. To support this process, the project team designed a Request for Information service (but time constraints meant that this could not be integrated into the Nexus Gateways).
A significant challenge in cross-border payments is that sanctions screening platforms generate high numbers of “false positives” ie alerts where the sender or recipient is not actually the person (or company) on the sanctions list. When this happens, further information on the sender or recipient can help to establish if this alert represents a true match against the sanctions list or a “false positive”. Alerts may be resolved automatically by software (which would normally take seconds) or passed to a member of staff for manual review (which could take hours or even days).
Nexus will therefore provide a Request for Information (RFI) service, based on ISO 20022 messages, that allows any PSP or SAP to request further information from either the Source or Destination PSP, in the hope that the additional information will be sufficient to eliminate false matches without manual intervention. The PSP receiving the request can choose not to send any further information, but any information they do share is likely to reduce the likelihood that the payment will trigger false alerts or require manual intervention. A PSP can also inform Nexus that they do not support RFI requests at all, in which case Nexus will not allow RFIs to be sent to that PSP.
The Request for Information process would be used to request the standard information about the sender or recipient that is commonly used in sanctions screening, specifically:
`Name
`Address (if not already provided)
`Date and place of birth
`National identity number or another unique identifier
An RFI can be issued at two points during the setup and processing of a Nexus payment:
When the Source PSP sends a proxy or account details to Nexus: If the Destination PSP has informed Nexus that it supports the RFI process, Nexus would automatically send an RFI request to the Destination PSP. If the Destination PSP responds with further information, Nexus will add this to the response to the Source PSP.
The benefit of this approach is that the Source PSP can use information about the recipient which has been verified by the Destination PSP (for example, against identity documents), rather than asking the sender to enter this information. When senders are asked to provide the recipient’s name, they can introduce inaccuracies (eg through typos or using a short name rather than the full legal name).
By a PSP or SAP during payment processing: The Destination PSP could send an RFI to the Source PSP, requesting further information on the sender (in the case that the Source PSP has not already included this information in the payment instruction). A Settlement Account Provider could send an RFI to the Source PSP and/or Destination PSP, requesting further information on the sender and recipient accordingly.
Admin portal
The Admin Portal (user interface) allows staff of IPS operators or the Nexus Scheme Organisation itself to update the information in Nexus, for example, adding new PSPs as they onboard, adding a new IPS, or adding a new proxy format.
The functionality in the Admin Portal can also be accessed directly via the Nexus APIs. For example, an IPS could set up their internal systems to automatically update Nexus via the API whenever they onboard a new PSP.
Testing service
The testing service allows IPS operators and PSPs to test that they are successfully integrated with Nexus by sending and receiving test payments, test proxy lookup requests or other calls to the Nexus APIs. The testing services use test data (ie no sensitive or real customer information). While the testing service in the proof of concept had limited functionality, a real-world implementation of Nexus would rely on a highly automated testing service that would allow each PSP to complete their testing at their own speed while requiring minimal support from the IPS operator or the operator of Nexus itself.
9. The Nexus scheme and governance framework
As part of the Nexus proof of concept, a dedicated workstream considered the scheme that would be needed to enable Nexus payments. An initial proposal is outlined below.
A payment scheme is a set of procedures, rules and technical standards that govern how payments are executed. As local IPS schemes cover only domestic payments, an additional scheme would be necessary to cover the cross-border aspects of Nexus payments.
A scheme rulebook defines the rights and obligations of the different participants in Nexus. A specified entity – the scheme owner – takes responsibility for maintaining and updating the scheme.30 The scheme owner in turn is governed via a formal “scheme management framework”. The scheme management framework describes how decisions about the scheme are made and how the scheme rulebook itself is updated over time (the change management process).
The Nexus Scheme Organisation
编辑搜图
图10:Nexus计划组织(NSO)的建议架构
Nexus would be managed by a governing entity and scheme owner, known provisionally as the Nexus Scheme Organisation (NSO). Key decisions in Nexus will be taken by the NSO Board. To ensure the Board’s effectiveness in discharging its responsibilities, the Board should be of an optimal size, with members representing key stakeholders in the Nexus Scheme such as IPS operators, FXPs, SAPs and PSPs together with a healthy number of independent members.
The NSO will have a management team of directly employed staff who manage day-to- day operations and relationships with participants. This management team will report to a managing director, who will in turn report to and be accountable to the NSO Board.
The management team will be advised by Expert User Groups, drawn from subject matter experts in each of the user communities (IPS Operators, FXPs and SAPs, and PSPs). These experts will help to review and assess proposed enhancements or changes to the Nexus technical standards, processes or scheme rules.
In addition, ad hoc working groups could be set up to address specific issues or challenges that need to be resolved as the Nexus Scheme develops. These working groups could be disbanded once their objectives are achieved.
Joint Oversight Forum
Payment system overseers (typically central banks), supervisors of FX providers and other relevant regulators in the Nexus participating countries would perform and coordinate oversight over the NSO through a Joint Oversight Forum. The forum would be led by a lead regulator and focus on ensuring the NSO has controls and processes in place that would prevent it from posing a risk to financial stability. The forum could advise the Board, and – where appropriate – issue directives to it.
The scheme rulebook
The specific rules and obligations for participants in Nexus are defined in the Nexus Scheme Rulebook. The participants must agree to adhere to the scheme (ie comply with its rules and obligations) before they can start processing Nexus payments or provide FX services.
IPS operators, FXPs and SAPs must adhere directly to the Nexus Scheme and interact with the NSO. In turn, IPS operators will manage the adherence of their member PSPs to the Nexus Scheme, for example by providing an addendum to the local IPS scheme containing some additional rules that would apply only to payments sent via Nexus.
Establishing a payment scheme is a significant undertaking requiring legal work and negotiation between different stakeholders. To limit the potential complexity, the Nexus Scheme is designed to have limited scope and to define only the requirements necessary to ensuring safe and reliable cross-border payments. It aims to avoid or minimise any changes to domestic IPS schemes. Importantly, the scheme does not change the clearing and settlement processes of the local IPS. It also does not alter the access criteria for PSPs when joining their domestic IPS, although any PSP who is a member of a specific Nexus-enabled IPS must adhere to an additional set of rules in order to send payments through Nexus.
A few highlights of the scheme rulebook are described below.
Fees and transparency
The Nexus Scheme Organisation would most likely run on a not-for-profit utility model, a common model for payment system operators. It would charge participants a membership fee and/or a per-transaction fee set to cover the NSO’s costs of operation plus a contribution to allow investing in service enhancements over time.The Scheme does not specify the fees that Nexus participants can charge each other for their services. However, the Scheme does set a number of requirements around transparency for the end users (payers and payees), specifically that:
PSPs and SAPs are not permitted to make deductions from the amount sent by the sender to the recipient. This ensures that the sender has certainty over the amount that will be credited to the recipient.
The Source PSP is permitted to charge transaction fees to the sender, but these fees must be charged as a separate line item.
The Source PSP is permitted to add a markup to the FX rate that they charge to the customer. The final FX rate (after any markup) must be shown to the customer.
Similarly, the Destination PSP can charge fees to the recipient, but these must be charged as a separate line item and not deducted from the value of the payment. The recipient is responsible for paying their own fees (if any) to the Destination PSP.
This arrangement gives the sender certainty over exactly what the recipient will receive and what the sender will be charged for sending that amount. It also provides PSPs with the flexibility to display their pricing in the way that makes commercial sense for them (eg either as a transaction fee, or embedded in the FX rate, or both). This is intended to provide transparency for end users without removing incentives for PSPs to participate in the scheme.
The scheme rulebook also states that:
IPS may charge PSPs for processing Nexus payments, at a level that is set by the IPS.
SAPs may charge FXPs for providing settlement accounts, at a level that is negotiated bilaterally between the SAP and FXP.
FXPs are not permitted to charge transaction fees; the FXP’s return or profit margin must be embedded in the FX rates that they offer to PSPs.
Compliance
Each participant in Nexus is responsible for complying with the laws and regulations that apply in its respective jurisdiction. In particular, AML and CFT sanctions screening remains an obligation of the PSPs sending and receiving a Nexus payment (Nexus itself does not perform sanctions screening). Nexus seeks to support this compliance by providing tools that help to reduce the compliance burden in cross-border payments. One such example is the Request for Information service, which allows any PSP or SAP to request further information from either the Source or Destination PSP, with the goal of reducing the number of false matches without manual intervention.
Likewise, the AML/CFT and any foreign exchange rules of the participating countries may require the sender to declare the purpose of cross-border payments. Differences in the category purpose codes adopted by each jurisdiction may compound the compliance burden for PSPs who have to manage separate lists for each country. Where possible, the Nexus scheme rules may seek to foster standardisation to mitigate the compliance burden across participating countries. One such opportunity is to align the category purpose codes used in Nexus payments with the ISO20022 External Code Set.
Data protection
Participants in Nexus are responsible for complying with the data protection and privacy regulations that apply in their country. They should also make it clear in their terms and conditions that some data will be shared for the purposes of making or receiving
cross-border payments. This is a challenging area where data protection rules may make it difficult to facilitate the flow of information across borders to meet compliance obligations around sanctions screening and know-your-customer requirements.
10. Lessons learnt from the proof of concept
The technical proof of concept revealed several opportunities to address challenges in connecting instant payment systems. In most cases, these challenges could be overcome through the flexible design of Nexus, but in some cases changes would be needed at a local level.
Differences in the addressing and proxy formats used in different countries
There is no global standard for addressing cross-border payments. International Bank Account Numbers (IBANs) are accepted in around 80 countries, but are not used in many markets, including Canada, Malaysia, Singapore or the United States. Domestic account details also vary in format and there are different ways of referring to a specific bank (or bank branch) or PSP (although BIC is usually available in addition to any local format).
Proxy formats also vary from country to country. In many countries, phone numbers are the only valid proxies, but other countries also provide proxies such as corporate registration numbers or virtual payment addresses. Again, many of these proxy types will have a unique domestic format (such as a different length of mobile phone number). Some countries have no proxy services at all.
Nexus accommodates this wide range of addressing formats by dynamically providing PSPs with the addressing and proxy formats available for a specific country (at the time that a payment to that country is being initiated) and enabling proxies used domestically to be mapped to account numbers for cross-border payments. This ensures that any valid account details or proxy format can be used, without every single PSP needing to understand the range of options in every other country.
Each participant in the technical proof of concept used the ISO 20022 message format for their domestic payments. Despite this, there were still cases in which certain elements (fields) in a message were used in differently in different countries. Other IPS (not participating in the proof of concept) use entirely different message formats, such as the much more limited ISO 8583 (typically used in card payments, but also in some IPS) or bespoke proprietary formats.31
The project team considered whether Nexus should be able to translate payment messages to each of the domestic formats. However, this would add significant complexity to Nexus itself, and may not meet the varying requirements of individual PSPs. Instead, the team concluded that Nexus should set usage guidelines for ISO 20022 messages used through Nexus. These usage guidelines are adapted from the CBPR+ usage guidelines. IPS who do not already follow these usage guidelines would need to translate their domestic messages to the “Nexus standard” ISO 20022 when sending messages to Nexus and translate back to the domestic format whenreceiving messages from Nexus.32 Greater harmonisation of the use of ISO 20022 would also improve interoperability between IPS and this is a priority of the G20 Roadmap for Enhancing Cross-Border Payments.33 The CPMI has recently issued a consultation paper on measures to harmonise use of ISO 20022 in cross-border payments.34
Differences in the internal processing of payments within an IPS
As each IPS has a specific way of processing payments internally, it is not possible to require all IPS to standardise on a specific “Nexus” approach. Instead, the Nexus scheme sets the requirement that funds must be secure before a payment instruction or confirmation is sent to Nexus and leaves it to the IPS to decide how to ensure this (for example, through immediate transfer of funds, through a funds reservation that locks up funds in the Source PSP’s accounts, or through a pre-funding arrangement where other funds are put aside to cover the obligations of a PSP that unexpectedly fails).
This approach ensures that a range of domestic settlement models can be accommodated. It also opens the door to other alternative payments infrastructure, such as CBDCs, to connect to Nexus provided that they can meet the same requirements of providing secured funds and instant payments.
Differences in network connectivity
Different IPS may use different connectivity models and different network service providers. For instance, some IPS use leased lines to connect to participants in a hub- and-spoke model, some have a private network that connects all participants to each other but which is physically separate from other networks, and others use a virtual private network over the same infrastructure as the internet. The challenge for Nexus is to connect to each of these IPS in a way that is cost-effective but which simultaneously meets the security requirements of each IPS. Doing this was outside the scope of the proof of concept but would need to be studied carefully in the next phase of the work.
The challenge of sanctions screening
Traditional cross-border payments apply sanctions screening after the payment instruction has been sent. If an alert is triggered, a payment may be sent for manual review by a member of staff and further information may be requested from the other bank, adding to administrative costs. On average, a false match against the sanctions list will result in a 24-hour delay to the payment.35 Sanctions screening is even more challenging in the context of instant cross-border payments, where there is no time for manual review of payments that trigger sanctions screening alerts.
First, by trying to enhance the data included in a payment instruction, either using information provided by the proxy resolution service, or via a direct Request for Information sent to the Destination PSP (the RFI service was designed but has not yet been built into the Gateway due to time constraints.)
Second, by providing a “non-time-critical” payment option, which gives a Destination PSP limited extra time (such as up to two hours) to review a payment before crediting it to the recipient (or blocking or rejecting it, as appropriate). In this case, the payment itself has been processed “instantly”, like any other Nexus payment and the funds have reached the Destination PSP, but the Destination PSP does not immediately credit them to the recipient.
Given that many sanction screening software services generate a high number of false positives, a slight delay seems to be preferrable to the alternative of rejecting many legitimate transactions. However, as banks and PSPs gradually move to more modern, API-based or even mutualised sanctions screening services,36 the number of false positives should start to fall and a growing percentage of payments should be processed instantly, right through to the recipient.
Inconsistent or conflicting regulatory requirements
Regulatory requirements differ between countries. For example, some countries require each payment to be labelled with a code describing the purpose of the payment. In some cases, the source and destination country will have different lists, and the sender must complete both. In addition, there is often a conflict between data protection regulations and the need to share high-quality verified information on the recipient for effective sanctions screening and compliance. In some jurisdictions (particularly the EU), banks often take a blanket view that data protection regulations prohibit them from sharing any customer data, even if this would be to the benefit of the customer.
Nexus partly addresses these issues through its flexibility. For example, the Reference Data Service will inform a Source PSP if the Destination Country requires a specific data element, such as the purpose code, to be included in the pacs.008 payment instruction. Nexus is also designed with fallbacks in the case that the Destination PSP is unable or unwilling to share information about the recipient. (In the worst case, the payment can still be sent relying only on information that is manually entered by the sender.)
Although the proof of concept revealed some of these challenges, further work is needed to map any incompatibilities between regulatory regimes and ensure that Nexus can accommodate all these differences.
The challenge of trivial incompatibilities
A significant proportion of unexpected delays to the proof of concept were due not to fundamental design problems, but to relatively trivial incompatibilities. For example, during testing (1) a proxy resolution request failed because the proxy resolution service in question expected a two-letter namespace prefix to be added to each element field, which was not used in the Nexus standard message; and (2) one payment system expected to receive payments through an synchronous API while Nexus was designed to send through an asynchronous API, making it technically impossible for them to talk to each other even with correctly formatted data. There are many more of these seemingly minor differences between payment systems, which can still cause payments to fail and take time and energy to work around.
Future-proofing Nexus for expansion
In most countries, there will be a single IPS and a single proxy scheme. However, in Europe and the United States, there are scenarios where a payment could be made through two or more IPS and there are multiple proxy schemes that could be queried to map a proxy to an account.
Nexus has already been designed to accommodate more than one IPS in a country. However, it would require further changes to accommodate the presence of more than one proxy resolution scheme.
Nexus also accommodates the scenario in which one IPS offers payments in two currencies. For example, Hong Kong SAR’s Faster Payments Service provides payments in both HKD and CNH.
However, to ensure that any design is future-proof, it is important to review the Nexus design against a wider range of payment systems.
These challenges will all be explored in more detail in the next phase of this work.
Annex 1: Technical architecture of Nexus Gateways
The Nexus Gateways developed in the Nexus proof of concept were built entirely on open-source components.
Figure 11: Technical Architecture of Nexus
编辑搜图
图11:Nexus的技术架构
API gateway
The API Gateway (using the WSO2 open-source software) provides a secure way for external parties, who are participants in Nexus, to communicate with the Nexus Gateways. The API Gateway also manages roles and permissions for distinct types of user (ie ensuring that only FXPs can submit new FX rates and only PSPs can submit payment instructions). On top of that, the API gateway is configured to know the REST API endpoints where external participants expect to receive asynchronous responses from Nexus (eg the Nexus payment service sends back the response message to the configured API endpoint of the matching Destination IPS). The next iteration of Nexus will need to accommodate alternative asynchronous communication models using externally accessible message queues (JMS, Kafka etc).
Communication between microservices and between Nexus Gateways
A JMS Message Broker (using ActiveMQ open-source software) is used to manage (a) internal communication between the microservices (described below) within a single Gateway and (b) external communication between two different Gateways. This ensures high processing throughput, as many instances of the same microservice can pull from the queue based on their current workload. JMS also prevents message losses that might occur due to critical errors within Nexus or if a Nexus Gateway must retain a
non-processable message for future investigation (using dead letter queues).
Admin portal
The admin portal is built using React and allows IPS operators to update Nexus with important configuration information, proxy formats and a list of PSPs that are onboarded with Nexus. (The same functionality can also be accessed directly via the Nexus APIs.)
Four loosely coupled microservices
Behind the API Gateway, there are four microservices, as described in Chapter 8.
Reference data service
This service stores the reference data that Nexus and PSPs need to be able to set up and process payments. Specifically, the service:
Accepts reference data from the IPS operators
Synchronises these data across all Nexus Gateways. (Some data will only be shared to certain Gateways if they are not required everywhere.)
Provides these data to PSPs (and other Nexus microservices) as required
Proxy service
This service is responsible for managing cross-border proxy resolution. The service:
Accepts proxy resolution requests from Source PSPs
Routes those requests to the appropriate proxy resolution service in the Destination Country
Validates whether the Destination PSP is onboarded with Nexus and able to receive Nexus payments
Returns the response (positive or negative) back to the Source PSP
Payment service
This service is responsible for coordinating payments across two IPS, as well as other payment related messages (such as payment return requests and status investigations). The service:
Accepts various ISO 20022 messages (such as pacs.008).
Validates messages
Transforms messages (for example, changing the instructing and instructed agents)
Forwards messages to the appropriate recipient
Records an audit trail
FX Service
This service is responsible for interacting with FX Providers and providing quotes to PSPs. The service:
Accepts rates and improvements (based on transaction size or requesting PSP) from FX Providers and distributes these across the network
Receives quote requests from Source PSPs, applies any improvements and then returns a list of quotes from various FX Providers
Provides the list of FXP accounts (intermediary agents in ISO 20022 terminology) to Source PSPs
Benefits of using a microservices architecture
The use of loosely coupled microservices supports the resilience and scalability of Nexus:
Each microservice will have its own data storage (persistence) layer that utilises JPA (Java Persistence API). Data are stored where they are required to keep dependencies and API calls between the services to a minimum.
Each microservice is built in Java Spring Boot and uses JAXB to handle ISO 20022 messages.
Changes and upgrades can be made to one microservice with minimal risk of disrupting other services. Resources (such as bandwidth, storage and processing power) can be allocated to each service depending on their specific requirements, in the most cost-effective way. For example:
º the FX service needs to be highly responsive and to handle a high volume of frequently changing data, so that new rates from FX Providers are always updated as quickly as possible.
º In contrast, the Reference Data Service stores a small amount of data, which rarely changes (weekly or even monthly); these data need to be provided to PSPs very quickly but do not need to be updated quickly.
º The conventional use of message queuing for payment instructions means that, although the payment service should respond as quickly as possible, the message queue itself can help to balance out the load on the payment service.
