Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
More than 60 countries already have instant (or "fast") payment systems that allow people to send money to each other within seconds. However, sending money abroad is often still slow and expensive. Connecting these domestic payment systems internationally could improve the speed, cost and transparency of cross-border payments.
Nexus is designed to standardise the way that these systems connect to each other. Rather than a payment system operator building custom connections for every new country that it connects to, the operator can make one connection to the Nexus platform. This single connection allows a fast payments system to reach all other countries in the network. Nexus could significantly accelerate the growth of instant cross-border payments.
This overview report explains the benefits of linking IPSs to provide cross-border payments and how Nexus could accelerate the growth of instant cross-border payments. It is the result of a 12-month proof of concept between the Eurosystem, Malaysia and Singapore. We recommend reviewing chapters 3, 6, 7 and 8 before digging deeper into the participant guides on this site.
This site contains detailed technical documentation, covering:
guides for each type of participant in Nexus
API and message specifications for Nexus
The Nexus blueprint was developed and refined through a 12-month proof-of-concept and over 50 workshops with IPS operators, central banks and large banks with a significant presence in FX markets and cross-border payments. We welcome further feedback and suggestions to enhance the blueprint.
Nexus is not yet operational, and the information on this site will be updated as the design of Nexus is refined and improved.
In the next phase of work, BIS IH Singapore Centre is collaborating with the central banks of Indonesia, Malaysia, the Philippines, Singapore and Thailand as they prepare to connect their domestic payment systems.
(Use of this website and the Nexus materials is subject to the terms and conditions.)
Below are two introductions to Nexus:
A 3-minute high level overview of the problem that Nexus aims to address
A 29-minute primer on Nexus. This is taken from a webinar on 5 April 2023 outlining the results of the technical proof of concept between the Eurosystem, Malaysia and Singapore.
This extract from a webinar held on 5th April 2023 explains the problem that Nexus solves, the results of the proof of concept between the Eurosystem, Singapore and Malaysia, and the lessons learnt for the payments industry.
We recommend starting by reading chapters 3, 6, 7 and 8 of the short report for a non-technical overview of how Nexus works.
The rest of this site gives a more technical overview of Nexus, tailored at professionals in the payments industry. Each section is focussed on a particular role in the Nexus ecosystem:
Payment Service Providers (PSPs)
FX Providers (FXPs)
Settlement Account Providers (SAPs)
Instant Payment System Operators (IPSOs)
Proxy lookup service operators (PLSOs)
The first section of each guide covers business and scheme-related aspects (eligibility, obligations, revenue models etc) while the second parts covers the technical integration between Nexus and the participant's systems.
There are also references to:
ISO 20022 messages used in Nexus
This site is a live document, and will be regularly updated with the latest specifications as the project advances. Please see the change log for a summary of changes.
We welcome feedback and suggestions for improvement to the design of Nexus is welcome - please contact the Nexus team at singapore.centre@bisih.org.
A PSP in Nexus can be any licensed financial institution that is:
A participant of a domestic that is a Nexus Scheme participant (or plans to be)
Able to send and receive instant payments through the domestic IPS (either through direct membership or some form of indirect or technical access)
Licensed by a central bank or equivalent regulator, and regulated or supervised for safety, soundness and conduct
Detailed eligibility criteria are defined in the Nexus rulebook.
A PSP must sign an adherence agreement with their domestic IPS to become a participant in the Nexus Scheme. The adherence agreement requires them to comply with the various obligations and responsibilities of being a PSP in Nexus, as defined in the Nexus Scheme rulebook.
The IPS Operator is responsible for managing the adherence and onboarding of its member PSPs.
When an IPS joins Nexus, it shares the full list of its members of that IPS with Nexus. However, PSPs do not automatically become onboarded and reachable through Nexus. Each PSP must first undertake a number of steps.
At the point of onboarding, a PSP must inform Nexus (via the IPS Operator) of:
the name of the PSP
the financial institution identifiers used by the PSP eg , and/or any custom domestic identifiers (such as Bank State Branch – BSB - codes in Australia).
whether the PSP supports the Request for Information (RFI) messages. (See Request for Information). If the PSP does, Nexus will send RFI requests to the PSP when preparing to send payments to the PSP’s customers.
which the PSP is a member of (ie in which payment systems can the PSP receive payments)
the go-live date from which the PSP is able to receive Nexus payments
The IPSO will input this information into the Nexus administration portal (which the PSP does not have access to).
To start receiving payments through Nexus, the PSP must:
Sign the adherence agreement with the PSP’s local IPS, committing to the rules and guidelines of the Nexus Scheme.
Confirm that all payments the PSP receives through Nexus will be screened against the sanctions lists applicable in the PSP’s jurisdiction (and that the PSP will apply with any other regulations and laws applicable in the PSP’s jurisdiction).
Sanctions screening is currently done at the payment processing stage, but pre-screening may be possible – for example when responding to a proxy resolution request – in future versions of Nexus.
The PSP will also need to:
ensure the PSP’s internal systems can handle and process the more data-rich Nexus-standard ISO 20022 messages. (The IPS may choose to translate the Nexus-standard messages into a domestic format before forwarding to the PSP.)
ensure the PSP’s internal systems will display useful information to the Recipient (for example, on the statement, including the Sender’s reference message, name and country)
update the PSP’s systems so that Nexus payment instructions received via the local IPS are identified as cross-border payments and screened before or immediately after they are accepted. (Domestic payments do not need to be screened against sanctions list, so this may require a change to the PSP’s workflow.)
undertake a robust testing process with the IPS Operator and the Nexus Gateway to ensure that all systems are working as expected
Upon completing the steps above, the PSP should inform their IPS Operator. The IPS Operator will then inform Nexus that the PSP is “Reachable” through Nexus and the PSP will be able to start receiving Nexus payments.
To send payments through Nexus, the PSP must additionally:
Update their mobile app and other channels to allow the Sender to set up Nexus payments (see Sending payments through Nexus for details)
Integrate the Nexus APIs into the payment setup flow
Ensure they can construct the Nexus-standard pacs.008 payment instruction (and other ISO 20022 messages used in the workflow) with all the necessary information
Complete a robust testing process with the IPS Operator and Nexus Gateway to ensure that all systems are working as expected
Every Nexus payment relies on an FX Provider (FXP), who:
Holds funds in two payment systems – the Source IPS (the instant payment system in which the Sender’s PSP is a member), and the Destination IPS (the instant payment system in which the Recipient’s PSP is a member), and
Quotes an exchange rate at which it is willing to swap the Source Currency (the sender’s currency) for the Destination Currency (the recipient’s currency)
Each corridor (pair of currencies) will have one or (ideally) more FXPs who will compete to offer the best rate for that currency pair. PSPs are free to select any FXP, as long as they have first onboarded with that FXP.
In the case that the PSP is also an FX Provider, the PSP-FXP can select themselves to act as the FX Provider for their own payments. See PSPs who are also FXPs.
For a specific Nexus payment, the FXP is effectively trading with the Source PSP by selling them the Destination Currency. This means the PSP is a corporate customer of the FXP. The FXP therefore has a regulatory obligation to complete due diligence (Know Your Business, KYB) on a PSP before it can provide FX conversion to that PSP.
A PSP can therefore only select quotes from FXPs with which it has completed the due diligence process.
Nexus will publish the list of FXPs and the IPSs to which those FXPs connect. The PSP must approach those FXPs bilaterally to initiate the onboarding and KYC process with the FXP.
Once the FXP has completed due diligence on a PSP, it will inform Nexus (via the Nexus administration portal or APIs) that it is willing to provide FX to that PSP.
When generating quotes in response to the GET /quotes/
API operation, Nexus will identify the quotes for which the FXP has approved the PSP.
Nexus will also include rates from other FXPs so that PSPs can see if other FXPs offer better rates; if so, the PSP may wish to onboard with additional FXPs.
The proof-of-concept version of Nexus does not validate whether an FXP has approved a PSP. This functionality would need to be added to a production version.
To ensure the FX market in Nexus is competitive, it is best if each PSP in an IPS is onboarded with each of the FXPs that provide FX in the PSP’s home currency. This means a PSP must apply to be onboarded with multiple FXPs, and each FXP must onboard multiple PSPs.
One challenge is that this due diligence can result in many KYB processes with significant duplication of effort. Some possibilities to streamline this onboarding process are outlined in FXP onboarding of PSPs.
This section describes how Payment Service Providers (PSPs) should prepare, send and receive Nexus payments.
There are three key roles that a financial institution can play in Nexus:
Payment Service Provider (PSP), sending and receiving payments on behalf of customers. This term is used inclusively to refer to any financial institution that can send and receive instant payments through a domestic instant payment system. It may therefore include both banks and non-bank payment service providers.
FX Provider (FXP), providing FX rates and FX conversion to PSPs
Settlement Account Provider (SAP), providing FXPs with accounts which can send and receive payments through a specific Instant Payment System (IPS)
The roles of FXPs and SAPs are described in more detail in separate guides. Each role has a distinct registration and onboarding process and set of obligations in the Nexus scheme, as well as a distinct set of permissions and security controls when using the Nexus APIs and messages.
One entity could choose to play more than one role, subject to eligibility. For example:
A PSP that is a participant in Nexus can also act as an FXP for certain corridors, subject to the eligibility requirements for FXPs. Such a PSP would be able to select their own quotes for the corridors for which they provide FX, and therefore provide FX conversion to their own payments. (See Annex: PSPs who are also FXPs)
A PSP could also act as a Settlement Account Provider, providing accounts to FX Providers who are not themselves members of the domestic IPS. (See Role of Settlement Account Providers for further details.)
Each PSP must comply with all applicable regulation and compliance obligations. In particular, PSPs must ensure that all payments sent through Nexus are screened against relevant sanctions lists.
A full list of obligations are defined in the Nexus Scheme Rulebook.
The Nexus Scheme Rulebook sets some basic requirements to ensure transparency for customers sending Nexus payments:
The Sender is responsible for any fees charged by the Source PSP
The Recipient is responsible for any transaction fees charged by the Destination PSP.
The Source PSP and Destination PSP can decide the level of fees it wishes to charge.
Any fees charged to Sender or Recipient must be billed separately. Deductions from the amount transferred are not permitted.
The Source PSP may choose to add a markup on the FX rate that they pay. They do not need to disclose this markup to the Sender.
Before the Sender approves the payment, they must be shown:
The exact amount (in the Source Currency) that will be deducted from their account
The exact amount (in the Destination Currency) that will be credited to the Recipient’s account
The effective exchange rate (between the amount deducted from the Sender’s account and the amount credited to the Recipient’s account) must be shown to the Sender before they confirm the payment
Any transaction fees that the Source PSP will charge the Sender
This framework ensures that:
The Sender has transparency and certainty over what they will be charged and how much the Recipient will receive.
The Source PSP has enough flexibility to find a commercially attractive pricing model, whether through marking up the FX rate or charging transaction fees.
Compared to traditional cross-border payments where the total fees and applicable FX rate may be unknown until the payment is completed, this offers much greater transparency and should also encourage competition between PSPs.
One limitation is that Nexus is not able to inform the Sender of the fees that the Destination PSP will charge the Recipient. This is because:
The Sender already has certainty over what will be credited to the Recipient’s account, as no deductions from the amount transferred are permitted. Therefore the Sender has certainty that – for example – they have paid the full amount of an invoice to the Recipient’s account. This means that any obligation between the Sender and Recipient has been settled.
Most PSPs do not charge fees for receiving payments, instead preferring to charge Senders. However, some PSPs who mainly receive payments (eg in countries that receive strong remittance flows) may not send many payments and may need to charge fees to Recipients to make the service commercially viable. Therefore it is not feasible to set a Nexus-wide fee model for receiving Nexus payments.
It is technically difficult to ask each PSP what they will charge for a specific payment, since that charge may depend on the account type (unknown to Nexus), the customer type and even the volume of transactions in a month.
Even if the Recipient’s fees are known to the Sender, this is not actionable information for the Sender. For example, if the Sender believes the Recipient is paying more than necessary for receiving a payment, it is unrealistic for the Sender to ask the Recipient to open an account with a more competitive PSP before making the payment. In addition, the Recipient has already signalled their willingness to pay those fees by providing those account details to the Sender.
The obligations of PSPs when using a proxy lookup service are defined in the Nexus Rulebook. In particular:
The PSP is obliged to only perform lookups for the intention of initiating a payment. However, there is no obligation to complete a payment after initiating a proxy lookup (for example if the Sender decides not to proceed with the payment).
When data is returned in response to a proxy lookup request, the PSP must use that data only for the purpose of processing this transaction, and not for any other purpose. (The PSP must not, for example, add the phone number that was used as an alias and the account name returned by the proxy service to their marketing database.)
The PSP must display the name (or nickname, depending on the scheme) of the account holder, as provided by the Proxy Lookup Service, to the Sender before they confirm the payment. This provides the Sender with greater confidence that they are sending funds to the correct account and reduces the change of the proxy being used for fraud.
The PSP must monitor the number of proxy lookup requests a specific Sender makes to ensure that they are not ‘phishing’ for account details. At a basic level, this may involve imposing a timeout for the user if they look up say, 5 different proxies in a short period without initiating a payment (ie a rate limit on lookup requests).
This section describes how PSPs should send and receive payments, in significant detail. It is intended for developers who will integrate a PSP's app and payment processing systems with Nexus.
For a simpler overview of how the Nexus payment process would appear to an end-user, and how the payment itself is processed, please see [SHORT REPORT].
For the payment process from the perspective of the PSP, continue to:
Sending payments requires updates to a PSP's app, as well as changes to the data included ina payment instruction
Receiving payments requires updates to the PSP's payment processing and sanctions screening workflows
For a much more detailed description on how payments are processed once they have been sent by the PSP to the local IPS, see:
In this guide we propose an ideal flow, which is designed to optimize the user experience. However, the Source PSP has the freedom and flexibility to call the APIs in a different sequence or to use only certain elements of the functionality provided through Nexus.
For the examples in this guide, Maria Rossi, who lives in Italy, wants to send SGD 150 to Wei Long who lives in Singapore.
For simplicity of the example, the exchange rate is 1.5000 (so EUR 1.00 = SGD 1.50).
This example is for a person-to-person (P2P) flow. However, a similar flow would be used for business-to-business (B2B) and business-to-person (and vice versa) payments (subject to any transaction size limits imposed by the instant payment systems).
The mobile app screens shown give an example of how a bank or PSP may implement Nexus into their existing app or online banking channels. They are mock-ups only – not a functional app. There is no dedicated Nexus app.
The general flow is summarised in the diagram below:
Using data retrieved from the GET /countries/
API operation, the PSP can display a dropdown Countries list to the Sender via the PSP’s app or other channel. (Left and middle figure below.)
The response to GET /countries/
lists all Nexus-enabled countries and the currencies available in that country. If the Sender selects a country with more than one currency, the PSP should immediately:
Display a second form element (eg <select>
or <radio>
) that lists the currencies available (Right hand screen below.)
Ask the Sender to select the currency that the Recipient expects to receive
The app should store the select country (and currency, if applicable) in memory, as it will be required when retrieving FX quotes
On the next screen, the PSP should now generate a form that will allow the user to define either:
The amount the Sender wishes to send (the Source Currency Amount), OR
The amount the Sender wishes the Recipient to receive (the Destination Currency Amount)
Different IPSs have different limits on the maximum value of a transaction. The GET /quotes/
API operation in Nexus will automatically apply these limits and reduce the Source Currency Amount or Destination Currency Amount accordingly. However, the PSP can also use client-side validation (eg setting the max
attribute of the HTML form input element) to cap the amounts that can be inputted:
The Source Currency Amount field (labelled “You send” in the example screen) can be capped to either:
the maximum value that the PSP is willing to send, or
the maximum value of the IPS to which the PSP is connected to. (This should be known by the Source PSP; it could alternatively be retrieved by calling GET /ipss/{country_code}
with the country code of the PSP’s home country.)
The Destination Currency Amount field (labelled “They receive” in the example screen) should be capped to the maximum defined in the /IPSs/IPS/MaxAmt
element that is returned in response to GET /ipss/{country_code}
with the country code of the Destination Country.
Where the IPSs element contains two or more Destination IPSs with different MaxAmt values, use the larger amount as the max
attribute on the form input element. Nexus will automatically calculate the maximum amount that can be sent for each specific quote depending on which IPS the FXP is a member of.
Once the Sender has entered either Source Currency Amount or Destination Currency Amount, the PSP should use the GET /quotes/
API operation to retrieve quotes (see FX Service APIs for more detail).
In the case that the PSP is also an FXP, they should still use this quote to retrieve current rates, as Nexus will generate a quote ID specific to this payment which must be referenced in the pacs.008 payment instruction. Without this quote ID, the exchange rate cannot be validated and the payment will fail.
Nexus will retrieve rates for the currency and country pair selected
For each rate, Nexus will:
automatically apply any improvements offered by that FXP based on size of the transaction or the PSP requesting the rate. (See Tier-based improvements and PSP-based improvements for more detail.)
check that the Source Currency Amount and Destination Currency Amount (at the given rate) do not exceed the MaxAmt
values in either the Source or Destination IPS, and adjust those values if they do.
calculate the amounts, in Source and Destination Currency, that can be sent at this rate. These are defined in the following fields in the response to GET /quotes/
:
AdjustedSourceAmount
AdjustedDestinationAmount
Where the Source Currency Amount or Destination Currency Amount provided by the Sender exceeds the MaxAmt
of the respective IPS, Nexus will apply whichever cap is the smaller at the current rate. This means the AdjustedSourceAmount
and AdjustedDestinationAmount
will never exceed the maximum that can be sent through the relevant IPS.
Nexus will then return the full list of adjusted and improved rates, with Quote Ids that are unique to this GET /quotes/
request. The Quote Id must be referenced when the PSP submits the pacs.008 payment instruction (or the domestic equivalent).
The GET /quotes/
API must be called again every time the Sender changes either the Source Currency Amount or Destination Currency Amount, since changes in the transaction value may (a) breach the maximum transaction value or (b) qualify for different size-based improvements to the rate.)
The PSP selects the quote that the PSP wishes to use (from any FXP with which is has already onboarded). This could be the best quote available or a quote from a preferred FX Provider.
The PSP does not show the list of quotes to the Sender.
In the case that the PSP also acts as an FX Provider, the PSP can select its own quote. Please note that when the PSP selects itself as FX Provider, the PSP need to have quotes registered as an FX Provider in Nexus. See PSPs who are also FXPs.)
Complications can arise when there are two or more IPSs in the Destination Country, and some quotes are only valid for one of those IPSs. See Selecting quotes when there are multiple IPSs in one country for details.
The PSP can also add a markup to the FX rate before it is shown to the Sender. PSPs may wish to mark up the FX rate they are provided by the FX Provider instead of (or in addition to) charging a transaction fee.
When the PSP applies a markup to the FX rate, the pacs.008 message should use the following elements in a specific way:
Instructed Amount = the amount deducted from the Sender’s account
Exchange rate = 1.5000 (the exchange rate agreed between the Source PSP and the FX Provider, as defined in the Source PSP’s preferred quote provided by Nexus
Interbank Settlement Amount = the amount the Source PSP actually transfers to the FXP’s Settlement Account Provider (rather than the amount deducted from the Sender’s account, which will be higher to account for the FX markup)
Now the exchange rate and Source Currency Amount and Destination Currency Amount can be shown to the Sender:
If the Source PSP does not plan to mark up the FX rate offered to the Sender, it can simply use the AdjustedSourceAmount
and AdjustedDestinationAmount
fields in the quote response to update the Source Currency Amount and Destination Currency Amount fields in the app.
If the Source PSP plans to mark up the FX rate offered to the Sender, it should calculate the Effective Rate (ie. Preferred rate from Nexus * PSP’s Markup = Effective rate)
If the Sender defined the Source Currency Amount, the AdjustedSourceAmount
should be multiplied by the (Effective) Rate to get the Destination Currency Amount
If the Sender defined the Destination Currency Amount, the AdjustedDestinationAmount
should be divided by the (Effective) Rate to get the Source Currency Amount
The Source PSP should confirm whether the amount originally requested by the Sender has been capped (because it exceeds the maximum amount in either the Source IPS or Destination IPS):
If the Sender defined the Source Currency Amount, AND this amount is greater than the AdjustedSourceAmount
, the Source PSP should add a notice to the Sender that the amounts have been adjusted to the maximum value that can be sent.
If the Sender defined the Destination Currency Amount AND this amount is greater than the AdjustedDestinationAmount
, the Source PSP should add a notice to the Sender that the amounts have been adjusted to the maximum value that can be sent.
The effective exchange rate applied (after any markup added by the PSP) should also be shown to the Sender
Next the PSP should provide the Sender with a form that allows them to select from the addressing formats available in the Destination Country and enter the proxy or PSP account details.
The form should first list the proxy formats, since these are usually easier for the Sender to input, followed by IBAN, followed by any domestic account formats.
See API - Proxy Service for instructions on generating this form dynamically using the GET /countries/{country_code}/proxyschemes/
. This API operation will return the list of proxy formats available in the destination country; this data can be used by the app to dynamically generate the form.
If the Destination IPS accepts IBAN or local account details, these can also be used through Nexus.
The PSP should check the whether the IBAN is accepted. This is defined in the IPSs/IPS/IBANAccptdInd
element. If IBAN is accepted (IBANAccptdInd = true
), this should be displayed in the addressing options field after the various proxy formats.
The PSP should also check whether a local account format is accepted, alongside a PSP identifier (such as BIC). This is defined in the /IPSs/IPS/LclAcctId/LclAcctIdAccptdInd
element of the response to GET /countries/{country_code}/ipss
. This option should be displayed last.
The PSP should ask the Sender to select either (a) a proxy (eg. phone number) or (b) a PSP identifier (eg BIC) and account details, depending on what information the Recipient has given them.
On the next screen (right pane in the diagram above), the Sender should be asked to enter the specific addressing details, depending on the option they selected before. (See API - Proxy Service for instructions to generate this form dynamically.)
The PSP should now send either the proxy or account details provided by the Sender to the GET /creditors/
API operation. This triggers the following steps:
If a proxy is provided, Nexus will send the proxy to the proxy lookup service in the Destination Country. (The proxy lookup service will map the proxy to a PSP identifier (eg BIC) and account number, or return an error if the proxy is not registered.)
Using the PSP identifier (provided by the proxy lookup service or by the Sender), Nexus will check that the Destination PSP is enabled to receive Nexus payments and able to apply sanctions screening to incoming payments (ie “Nexus reachable”). If not, Nexus will return an error (“Destination PSP not reachable”).
Nexus will check whether the Destination PSP supports the Request For Information process. If so, it will contact the Destination PSP via the RFI
API (or a camt.026 message) to request verified information about the Recipient, such as the name and address, so that the PSP doesn’t need to ask the Sender for this information. (See Request for Information)
Nexus will respond to the PSP with:
the PSP identifier
the account number
a list of the IPSs in which the PSP is reachable
the Recipient’s name or nickname (as provided by the proxy service or the response to the RFI)
any further personal data on the Recipient that Nexus is able to retrieve from the Destination PSP via the RFI.
The PSP should now ask the Sender to confirm that they recognize the Recipient’s name or nickname before proceeding with the payment. The confirmation of payee step allows the Sender to verify that the holder of the Destination Account is actually the person or business they intend to pay. This provides a check against fraud as well as giving the Sender greater confidence that they entered the proxy or account details correctly.
In most cases, the response to the Creditors response will include either the Recipient’s real name or a nickname defined by the Recipient. This information is retrieved from either:
the proxy lookup service in the Destination Country, or
the Request for Information sent directly to the Destination PSP
The PSP should show this to the Sender and ask them to confirm that this is the name they are expecting to see.
In some cases, the nickname and real name fields will both be blank. This can occur when:
The Destination PSP does not support RFI, AND either:
The proxy lookup service itself does not store or provide the account holder’s name or nickname OR
The Sender provided a local account number (so there was no proxy lookup)
In this situation, there is no way for the Sender to confirm the identity of the Recipient and this confirmation-of-payee step can be skipped. In such cases, the Sender must send the payment “blind” to the real identity of the account holder. This may increase the risk of them making a payment to a fraudulent or mistaken account.
This is one reason why it is alway preferable to list the proxy options first in the addressing form, rather than IBAN or a local account number. (Most proxy schemes will return a name or nickname but it is possible that many banks will not support the RFI process.)
Now that the Sender has approved the payment, the PSP must set up the Nexus-standard pacs.008 payment instruction which will be submitted to the local IPS.
The PSP constructs the pacs.008 payment instruction: this will make use of information from the earlier responses to the following APIs:
GET /quotes/
GET /creditors/
GET /intermediaryagents/
NORM
: default, for all payments that are not urgent or time-critical. This flag will allow the Destination PSP extra time (to be defined in the Nexus scheme rulebook) to complete sanctions screening in the event the payment triggers an alert.
HIGH
: for urgent payments and physical point-of-sale payments (where the customer cannot leave the store until the payment is confirmed). If HIGH
is used, the Destination PSP will reject any payments that it cannot immediately accept. Payments marked HIGH
are more likely to be rejected if the Destination PSP does not have real-time sanctions screening systems. They will also be rejected if the payment generates a sanctions alert which the Destination PSP cannot resolve without manual intervention. This means that HIGH
should not be used unnecessarily.
Once the Sender has confirmed the payment, the PSP should submit the pacs.008 payment instruction to the Source IPS (using the same secure connection that the PSP normally use to submit domestic payment instructions to the IPS). ]
Nexus will coordinate the payment between the Source and Destination Countries.
Checking for duplicated or fraudulent payments
In general, Nexus trusts the Source PSP and assumes that any payment instructions received from the Source PSP are legitimate and should be processed. It is therefore the responsibility of the Source PSP to defend against sending fraudulent payments or payments that were sent in error.
Nexus uses the UETR (Unique End-to-End Transaction Reference) to check whether a payment is unique. Nexus will check whether a payment with the same UETR has already been processed, and will not process duplicates.
However, Nexus will not check whether similar payments with different UETRs are possible duplicates. For example, if a Source PSP sends two payments, for the exact same amount, between the same sender and recipient accounts, but with different UETRs, Nexus will assume both payments are intentional and will process both.
Nexus does not currently have any fraud prevention tools or transaction monitoring, although this could be added to the roadmap in due course.
The proof of concept uses End2EndId as the unique identifier, but a production version will need to use UETR. This is because we cannot be sure that the End2EndId for a specific payment will be universally unique across all PSPs and all IPSs in Nexus, whereas UETR is by definition universally unique (as it is generated as a Universally Unique Identifier – UUID.)
The PSP should now ask the Sender to review all details before confirming the payment.
The Nexus scheme has specific requirements on the minimum information that should be shown to the Sender, to ensure transparency around the costs and FX rates that will be applied to the payment. The PSP should display:
The Source Currency Amount – the amount that will be deducted from the Sender’s account
The Destination Currency Amount – the exact amount that will be credited to the Recipient’s amount
The fees that the Sender will be charged by the Source PSP. As per the Nexus rulebook, these must be charged to the Sender as a separate line item rather than as a deduction from the amount transferred.
The PSP can also offer the Sender a field to add a message/reference to the payment, which will be visible to the recipient. This message can be stored in the /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/RmtInf/Strd/CdtrRefInf/Ref
element of the pacs.008. (The message field can alternatively be added at any other point in the flow.)
All cross-border payments through Nexus will need to be screened by the PSPs involved in a payment against the sanctions lists that apply in their jurisdiction (‘sanctions screening’). In most cases, sanctions screening software used by the PSP will first compare the name of the Sender or Recipient and look for similar names on the sanctions lists. If a positive ‘hit’ is found, the software can use additional data, such as address, date and place of birth, or national identity number, to confirm whether the Sender or Recipient is actually the person on the sanctions list or just a similar name (a “false positive”).
For the Sender:
The name of account holder (Mandatory)
The account number
AT LEAST ONE OF THE FOLLOWING:
Address
Place and date of birth
National ID number or another unique customer identification number
For the Recipient:
Recipient (Beneficiary) Account Number
Recipient (Beneficiary) name
Additional requirements may apply in each jurisdiction. For example, a particular country might define the Creditor > Postal Address element to be mandatory.
Each IPS can define this required information in Nexus, through the Reference Data Service, so that it can be shared with PSPs.
The PSP should now review the Creditors
response to confirm whether:
Name is present (Nickname is not sufficient for sanctions screening)
At least one of the other data points specified in FAFT Recommendation 16 (see above) is present
If the Name
element is blank, the PSP must display a form asking the Sender for the Recipient’s full name. (The Recipient’s name is required as a minimum, in line with FATF Recommendation 16.)
The PSP can display fields for them to enter the Recipient’s address. The PSP should check the information it received from GET /countries/{country_code}/upss
to establish if these additional fields are mandatory in the Destination IPS.
Although the PSP could also ask for Date and Place of Birth and National Identity number, Recipients may be uncomfortable with sharing this information directly with the Sender. (In contrast, when the Destination PSP shares the information in response to an RFI request, the information is shared securely through Nexus and not shown to the Sender, except for the Name).
Before the PSP send the payment instruction the Source PSP will need to screen the Recipient against the sanctions lists applicable in the PSP’s jurisdiction. (It is assumed that the Sender will already have been screened by the Source PSP as part of the PSP’s regular KYC, AML and screening processes.)
(This step can be done later if the PSP's screening software requires a complete pacs.008
payment instruction.)
If the Destination PSP supports RFI, Nexus will already have issued an RFI to the Destination PSP during the POST /creditorrequests/
API process. So there is no need for the Source PSP to issue a further RFI to the Destination PSP at this point.
The PSP uses the API operation to retrieve the Intermediary Agents, based on the ID of their preferred quote. This information is used in the pacs.008 message to specify the accounts held by the FX Provider in both the Source and Destination country. Funds will be paid into the FXP's account in the Source Country and paid out of their account in the Destination Country.
The Source PSP should define whether the payment is , by setting the Instruction Priority (/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/
) as follows:
See for further details.
If the Source PSP supports the Request for Information (RFI) service, the Source PSP should be prepared to respond to any RFIs relating to this payment. These requests could come from either of the Settlement Account Providers or the Destination PSP. (See for further details.)
The exchange rate that will be applied – this is the effective exchange rate paid by the Sender, after any markup applied by the Source PSP, rather than the exchange rate paid by the Source PSP to the FXP. (See .)
requires the following information to be included in cross-border payments:
The PSP should therefore ensure that all (pacs.008
) payment instructions to Nexus include the Recipient’s name as a minimum. Failure to include this basic information will result in the payment failing the sanctions screening of PSPs and involved in the payment. Adding further information in addition to the name will reduce the likelihood of the payment triggered a false positive hit and being delayed.
The exact workflow for a Destination PSP receiving a Nexus payment will depend on:
the PSP’s internal systems
whether the PSP has real-time / near-instant sanctions screening capability
whether the PSP supports the Request for Information process
Incoming Nexus payment instructions will be sent to the Destination PSP via the same method as domestic payment instructions (eg API or message queuing via the Destination PSP’s existing secure connection to the IPS).
The Destination PSP must accept the full comprehensive Nexus pacs.008 message (which will have more elements than a domestic payment message).
The domestic IPS may choose to translate the Nexus pacs.008 message to a domestic format; in this case, the domestic IPS will be responsible for defining the domestic message standards for Nexus payments and ensuring that it carries all the data necessary to support sanctions screening and comply with other regulations.
Before the Destination PSP accepts the payment instruction, it will need to screen the Sender against the sanctions lists applicable in the Destination PSP’s jurisdiction.
It is assumed that the Destination PSP will already have screened the Recipient as part of the PSP’s regular KYC, AML and screening processes on its own customer database.
The specific screening process and software used will vary from PSP to PSP.
As Nexus payments are supposed to be instant, it is preferable for PSPs to use a real-time API-based sanctions screening platform that can deliver a decision prior to accepting the payment, rather than legacy systems that screens transactions retroactively. (See below for options when the PSP cannot immediately screen against sanctions lists.)
If the payment triggers an alert against the sanctions lists, the Destination PSP may issue a Request-for-Information (RFI) process to the Source PSP to request further information on the Sender. This is described in detail in Request for Information, but in summary:
Nexus will check if the Source PSP is able to process RFIs (based on the information provided by the IPSO when it first onboards the PSP);
If not, Nexus will respond with a camt.029
informing the Destination PSP that no further information is available (status code = NINF
).
Otherwise Nexus will forward the request to the Source PSP.
When the Source PSP sends a response, Nexus will forward that response to the Destination PSP, as a camt.028 AdditionalPaymentInformationV11
.
The Destination PSP must respond to Nexus with a pacs.002
within the timeout (maximum execution time) of the Destination IPS. The Destination PSP’s response will depend on whether the payment is time-critical or non-time critical:
If the Destination PSP is happy to accept the payment, they should immediately credit the Recipient and send a pacs.002
to Nexus with the status code ACCC
If the Destination PSP cannot immediately credit the Recipient (for example, because they need more time to resolve a sanctions screening alert, then they must:
Review the Instruction Priority element of the pacs.008
(/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/
)
If the Instruction Priority is HIGH
and the Destination PSP cannot immediately credit the Recipient, the Destination PSP MUST reject the payment by sending a pacs.002
with the status code “RJCT” to Nexus. Any reservation or movement of funds in either IPS will be cancelled/reversed automatically.
If the instruction priority is NORM
, the Destination PSP may accept the funds now, without crediting them to the Recipient. The PSP can then take an additional period of time (to be defined in the Nexus Scheme Rulebook) to resolve the sanctions screening alert.
The Destination PSP should immediately respond with a pacs.002 with the status code ACWP (Accepted Without Posting)
Within the time defined in the Nexus Scheme Rulebook, the Destination PSP must send a second pacs.002
with one of the following status codes:
ACCC – if the payment was successfully credited to the Recipient
BLCK – if the funds were blocked due to a true positive hit against the sanctions list
RJCT – if the Destination PSP was unable to resolve the alert within the SLA defined by the Nexus rulebook
In this case, the Destination PSP will also need to submit a pacs.004
to return the funds.
Nexus will return the pacs.002
to the Source PSP, who will notify the Sender accordingly.
A Destination PSP may need to return the funds in the following scenario:
The Instruction Priority in the pacs.008
was NORM
, AND
Sanctions screening generated an alert, AND
The Destination PSP initially responded with a pacs.002
with the status ACWP
(Accepted without Posting), AND
The Destination PSP was then unable to review the sanctions alert within the SLA defined in the Nexus rulebook.
In this case, the Destination PSP is unable to decide either to credit the Recipient or to block the funds. The Destination PSP must therefore return the payment to the Source PSP.
This is done by submitting a pacs.004
instruction to the Destination IPS. See the next section, Payment Reversals, for further details.
This return will be processed at the original exchange rate.
For every cross-border payment, a Destination PSP must screen the Sender and Recipient against the sanctions lists applicable in that jurisdiction. However, not all PSPs are able to do this instantly:
Some banks have legacy screening systems that screen payments after the funds have been received by the bank, but before they credit those funds to the recipient. These systems may not be technically capable of making a decision quickly enough (ie within the timeout / maximum execution time of the domestic IPS system)
For other banks, even if they can perform an initial screen on the payment “instantly”, they may not be able to resolve any alerts without manual intervention, which cannot be done instantly.
Screening software typically generates a high number of false alerts. To avoid PSPs simply rejecting any payment that triggers an alert (and therefore rejecting a large number of legitimate payments), Nexus allows for payments to be flagged as time-critical or non-time critical:
Time-critical payments include urgent payments and point-of-sale payments (eg where the Sender is standing in a shop, waiting for a payment to complete before they can leave):
The Source PSP should set the pacs.008
instruction priority to HIGH
(pacs.008 element /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/
)
Within the timeout SLA of the Destination IPS, the Destination PSP must either:
Accept the payment and credit it to the Recipient, OR
Reject the payment
Payments should be non-time critical if it is acceptable for the payment to be slightly delayed in the case that the sanctions screening process triggers an alert (false or otherwise). In many cases, a potential delay might be preferable to the payment being rejected outright by the Destination PSP.
The Source PSP should set the pacs.008
instruction priority to NORM
(pacs.008 element /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/
)
Within the technical timeout of the Destination IPS, the Destination PSP must respond with a pacs.002 with status:
ACCC
– accepted and credited to recipient
RJCT
– rejected
ACWP
– accepted without posting to the Recipient’s account
Note that the Destintion PSP must still respond with a status within the timeout of the Destination IPS (typically 30 seconds or less), so the Sender will still have certainty about the status of the payment.
If the Destination PSP responds with the status code ACWP,
the Destination IPS will still credit the funds to the Destination PSP, but the Destination PSP will not immediately credit funds to the Recipient.
From Nexus's perspective, all payment processing through the IPSs is now complete. But further steps are required to update the Sender on the final status of the payment.
If the Destination PSP responds with ACWP, then within the time limit set in the Nexus Scheme Rulebook, the Destination PSP must respond with:
ACCC
– funds now credited to the recipient
BLCK
– funds blocked and will not be returned (due to suspicious or illicit activity)
RJCT
– payment rejected (in case the Destination PSP could not resolve the case within the SLA)
In this case, the Destination PSP will issue a pacs.004
to return the funds
The Nexus Scheme Rulebook would define the maximum time in which an ACWP payment must be credited to the Recipient, blocked or rejected and returned.
We will engage with the industry to establish a reasonable time limit for processing ACWP
payments. A trade-off needs to be made:
A very short time limit will increase the number of legitimate payments that are rejected due to false alerts from sanctions screening.
A very long time limit will ensure the greatest percentage of legitimate payments are ultimately successful, but at the expense of uncertainty for the Sender and Recipient
As more banks/PSPs transition to real-time, API-based sanctions screening software, the average time required for resolving alerts should fall. If so, the Nexus Scheme could also reduce the time limit for processing ACWP payments.
In Nexus, the Source PSP, Destination PSP, and Settlement Account Providers (SAPs) must screen the Sender and Recipient against the sanctions lists applicable in their jurisdiction to check that neither party is on the sanctions list.
One challenge is that sanctions screening systems 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 an 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).
To support this process, Nexus will provide a Request for Information (RFI) service 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 Request for Information 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
A PSP can choose whether or not to share this information. (A PSP can also opt out of responding to RFIs entirely, if it does not have the technical capacity to do so, although this will be detrimental for their own customers.)
An RFI can be issued at two points during the setting up and processing of a Nexus:
By Nexus, during the POST /creditorrequests/
process:
When a Source PSP makes a call to the POST /creditorrequests/
API operation, Nexus will use the RFI process to contact the Recipient’s bank and ask for further, verified information about the Recipient, so that the Source PSP does not have to ask the Sender to enter this information (which the Sender may not know or may enter incorrectly). This step will only be done when the Destination PSP has earlier informed Nexus that it supports the RFI process.
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
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.
(Since Nexus would already attempt an RFI to the Destination PSP during the POST /creditorrequests/
process, there is no need for the Source PSP to call the RFI API directly.)
There are three ISO 20022 messages involved in the Request for Information process:
First, the “requestor” (the PSP or SAP asking for further information about another PSP’s customer) sends a camt.026 “UnableToApply”
message. This message acts as the information request. (The “UnableToApply” message name represents that the payment cannot be processed without further information).
The “requestee” (the PSP that is receiving the request for further information about their customer) should first reply with camt.029
“ResolutionOfInvestigation”, with one of two status codes:
“NINF”
: ie no further information is available” or
“INFO”
ie Further information to follow
If further information is available, the requestee will send a “camt.028 AdditionalPaymentInformation” message with the request information.
When the Destination PSP accepts the pacs.008, they will respond with a pacs.002, which will be sent back to Nexus. Nexus will forward the pacs.002 to the Source IPS, who will forward it to the Source PSP.
For pacs.008s with an instruction priority of HIGH, the pacs.002 will have one of the following status codes (found in /Document/FIToFIPmtStsRpt/TxInfAndSts/TxSts/
):
ACCC
: the Destination PSP has accepted the payment and credited the Recipient’s account
The Source PSP should inform the Sender that the payment has successfully reached the Recipient
RJCT
: the Destination PSP payment has been rejected. A reason code may provide further information. In the Source IPS, any reservation of funds against the Source PSP has been cancelled and any movement of funds from the Source PSP to the Source Settlement Account Provider has been reversed.
The Source PSP should inform the Sender that the payment could not be made.
For pacs.008s with an instruction priority of NORM, two addition status codes are possible (in addition to ACCC and RJCT):
ACWP
: The funds have reached the Destination PSP, but have not yet been credited to the Recipient’s account. This may be because the payment triggered a sanctions screening alert which needs to be manually reviewed.
When ACWP
is received, the Source PSP must inform the Sender that the payment is still being processed but has not yet been credited to the Recipient. The Source PSP should ensure the Sender knows how to confirm if/when the payment has been completed (eg via a notification from the app, or by checking their statement)
An ACWP
response will be followed up later with one of the following outcomes. The follow-up response must be set within the SLA time defined in the Nexus Rulebook (currently proposed to be 2 hours):
A pacs.002 with the status ACCC
, meaning that the Recipient’s account has been credited.
A pacs.002 with the transaction status BLCK
, meaning that the funds will not be returned to the Sender and have not been credited to the Recipient. This is most likely in the case that the payment was identified to be illicit after sanctions screening.
A pacs.002 with the transaction status RJCT
meaning that the Destination PSP has been unable to ascertain whether the payment can be accepted or not. This may mean that the Destination PSP was unable to manually review a sanctions screening alert within the time limit defined in the Nexus Scheme Rulebook.
This will be followed by a pacs.004 message returning the funds.
The Source PSP should inform the Sender that the payment has been unsuccessful and that the funds will be returned to the Sender’s account.
When the ACCC message is received, the Sender should be notified (possibly through a notification or update on the app/online banking, or via an update to their statement).
There are two circumstances in which a payment reversal may be required:
Subject to the dispute window specified in the Nexus Scheme Rulebook (to be defined in the next phase of this work) a Source PSP may request the return of a previously completed Nexus payment. This request may be made if the original payment turns out to have been made in error, duplicated or fraudulent (for example).
A payment reversal may also be needed when the Destination PSP originally responded with the status ACWP
(Accepted Without Posting) but is unable to resolve the payment within the time defined in the Nexus SLA. (In this case, Steps 1-2 are redundant and will be skipped.)
The process for reversals is as follows:
The Source PSP must submit a camt.056 FItoFIPaymentCancellationRequest
to the Source IPS referencing the original pacs.008
payment instruction.
The camt.056
will include the reason for the cancellation in the /Document/FIToFIPmtCxlReq/TxInf/CxlRsnInf/Rsn/Cd
element, using the ExternalCancellationReason1Code from the ISO 20022 External Code Set. Possible values are:
Other ExternalCancellationReason1Codes may also be used, but PSPs should ensure they are familiar with at least the set above.
This camt.056
will be forwarded by the Source IPS to the Nexus Gateway, and in turn to the Destination PSP.
Full camt.056
message specs are available at [LINK TO FOLLOW].
Within the time allowance defined in the Nexus Scheme Rulebook, the Destination PSP must reply with a camt.029 ResolutionOfInvestigation
message with the following status:
If the Destination PSP is willing to return the payment:
The status element (/Document/RsltnOfInvstgtn/Sts/Conf/
) element should be set to a ExternalInvestigationExecutionConfirmation1Code from the ISO 20022 External Code Set, such as:
CNCL
– confirming the payment has been cancelled and the funds will be returned as requested
If the Destination PSP is not willing to return the payment:
The status element (/Document/RsltnOfInvstgtn/Sts/Conf/
) element should be set to a ExternalInvestigationExecutionConfirmation1Code, such as:
RJCR
– the cancellation request has been rejected
The reason code for the rejection (/Document/RsltnOfInvstgtn/CxlDtls/TxInfAndSts/CxlStsRsnInf/Rsn/Cd/
) element should be set to an ExternalPaymentCancellationRejection1Code from the ISO 20022 External Code Set. Examples include:
CUST
(CustomerDecision to refuse the return)
NOAS
(NoAnswerFromCustomer)
Full camt.029
message specs are available at [LINK TO FOLLOW].
The Destination PSP must now submit a pacs.004 PaymentReturn
message to the Destination IPS. This will be processed in a similar way to the pacs.008
, but in reverse, so that the funds are returned to the Source PSP and will be re-credited to the Sender.
Note that reversals are processed at the same FX rate used in the original pacs.008 payment instruction.
Full pacs.004 message specs are available at [LINK TO FOLLOW].
Every cross-border, cross-currency payment requires an actor who is willing and able to swap one currency for another. In Nexus, the entity providing this service plays the role of FX Provider.
This is one of the three key roles that a financial institution can play in Nexus:
Payment Service Provider (PSP), sending and receiving payments on behalf of customers
FX Provider (FXP), providing FX rates and FX conversion to PSPs
Settlement Account Provider (SAP), who provide FXPs with accounts which can send and receive payments through a specific Instant Payment System (IPS)
In Nexus, each corridor (currency pair) will have one or more FX Providers, who are in competition with each other to provide the best rates.
Playing multiple roles in Nexus
An FXP could choose to play more than one role in Nexus, subject to eligibility. For example:
In Nexus, a rate refers to the rate at which an FXP is currently willing to exchange one currency for another. A rate is not specific to a single transaction or PSP. Rates are valid until an FXP sends an updated rate.
Nexus uses rates uploaded by the FXP to generate quotes which are provided to Source PSPs whenever they call the GET /quotes/
API operate. Quotes are specific to the PSP making the request, and are valid for a set period of time (a few minutes).
The Source PSP must reference the Quote ID in a payment instruction (pacs.008
) so that Nexus can verify the exchange rate specified before it forwards the payment instruction to the Destination Country.
An overview of the process for generating and processing rates and quotes is given in detail below. Further details are given in later sections.
An FXP uses the POST /rates/
API to inform Nexus of the (base) rate at which they are willing swap the Source Currency (the Sender’s currency) for the Destination Currency (the Recipient’s currency).
A rate in Nexus describes the ‘going rate’ at which an FXP is willing to swap one currency for another.
The rate is not specific to a single transaction. FXPs are not asked to quote or bid on individual transactions. This means that when an FXP provides a rate to Nexus, they are effectively saying “Until further notice, for any Nexus payment, I’m willing to exchange Currency A for Currency B at exchange rate X”. “Further notice” is given when the FXP sends another revised rate via the POST /rates/
API.
When a Sender initiates a payment, the Source PSP will ask Nexus for quotes for that specific corridor.
Nexus will retrieve rates from all FXPs that provide FX to that corridor
Nexus generates a list of payment-specific quotes with unique quote IDs. Each quote describes a specific rate (with any improvements already applied) offered to a specific PSP by a specific FXP for a specific corridor (pair of currencies).
A PSP can select a quote from any FXP, as long as they have completed an initial KYC process with that FXP.
Assuming that the Sender accepts the final exchange rate offered by their PSP, the Source PSP will initiate a payment instruction by sending a pacs.008
message to the Source IPS.
The message will include the quote ID so that Nexus can validate that the exchange rate included in the pacs.008
is correct.
As the payment is processed, the FXP will:
Receive funds from the Source PSP via the Source IPS
Pay out funds to the Destination PSP via the Destination IPS
When the payment is completed, the FXP holds more of the Source Currency and less of the Destination Currency in its accounts in the Source IPS and Destination IPS respectively.
From the perspective of the FXP, this process is equivalent to a trade where they buy (receive) the Source Currency and sell (pay out) the Destination Currency. Because the FX Provider is selling one asset (the Destination Currency) for another (the Source Currency), the FXP gets to determine the “price” ie. the FX rate at which it is willing to swap those assets.
In a conventional FX trade, the FXP would “deliver” the Destination Currency to the buyer (in this case, the Source PSP). However, in Nexus, the FXP delivers the Destination Currency directly to the Destination PSP. This enables the Source PSP to make a payment to the Destination PSP, even though the Source PSP never directly holds the Destination Currency.
Any FX Provider that meets the and adheres to the Nexus Scheme may provide FX to Nexus payments.
The roles of and are described in more detail in separate guides. Each role has a distinct registration and onboarding process and set of obligations in the Nexus scheme, as well as a distinct set of permissions and security controls when using the Nexus APIs and messages.
Where an FXP is a member of a specific IPS (see ), the FXP in effect acts as Settlement Account Provider to themselves. In this case, the obligations that apply to an SAP also apply to the FXP.
A PSP that is a participant in Nexus can also act as an FXP for certain corridors, subject to the prerequisites above. Such a PSP would be able to select their own quotes for the corridors for which they provide FX, and therefore provide FX conversion to their own payments. (See )
An FXP can define whether larger transactions qualify for improved rates (See ). Each FXP can set their own tiers with minimum thresholds at which a transaction qualifies for a specific improvement.
An FXP can also instruct Nexus to improve the rates it offers to specific PSPs (See ).
For each FXP's rate, Nexus will apply any improvements that apply based on the size of the transaction () or the requesting PSP ().
The rate provided to the Source PSP is the rate that the FX Provider charges to the Source PSP. The Source PSP could choose to before displaying it to the Sender.
camt.056 CANCELLATION REASON CODE
CODE MEANING
AM09
WrongAmount
CUST
RequestedByCustomer
DUPL
DuplicatePayment
FRAD
FraudulentOrigin
TECH
TechnicalProblem
An FX Provider can be any licensed financial institution that is:
Willing to quote FX rates for specific corridors between Nexus countries (ie. from currency A in IPS-A to currency B in IPS-B). These rates will be shown to Source PSPs when any PSP calls the GET /quotes/
API.
Able to hold funds in at least two instant payment systems (IPSs), either directly through membership of the IPS, or indirectly through a Settlement Account Provider (SAP). (See Accessing Instant Payment Systems below.)
Licensed to perform the role as FX Provider by their regulator, and compliant with all relevant regulatory requirements.
An FXP must sign an adherence agreement to become a direct member of the Nexus Scheme. The adherence agreement requires them to comply with the various obligations and responsibilities of being an FXP in Nexus, as defined in the Nexus Scheme rulebook.
At the point of onboarding, an FXP must inform Nexus of:
The corridors (currency pairs) that it wishes to quote for.
The IPSs in which it is able to hold funds (either through membership or via Settlement Account Providers – see next section)
For each IPS, whether the FXP accesses the IPS through
(a) membership of the IPS or
(b) indirect access via a Settlement Account Provider (See Accessing Instant Payment Systems)
For IPSs where the FXP is a member (ie the FXP acts as SAP to itself):
the FXP's in that country. (This is used to identify the FXP's settlement account to and from which payments should be made.)
For IPSs that the FXP accesses via a separate SAP:
the BIC of the FXP's Settlement Account Provider, and
the number of the FXP's account at that Settlement Account Provider
This information is stored by Nexus and used to route payments to and from the FXP's account in various countries. It is provided to PSPs when they call the GET /intermediaryAgents/
API operation with a valid quote ID.
An FXP must be able to send and receive payments in a specific IPS in order to offer rates on payments to/from that IPS and currency.
There are two options for the FX Provider to access an IPS: membership, or use of a Settlement Account Provider.
In this model, the FXP is a member of the IPS. This means that:
the funds in this settlement account can also be used for processing Nexus payments
the FXP is able to directly initiate payments through the IPS
This option is only available to banks and non-bank PSPs who are eligible for membership of the IPS.
FX Providers who are not eligible for membership of an IPS will need to access the IPS indirectly via a Settlement Account Provider. In this model an FXP holds an account at an existing IPS member. This means that:
The SAP provides an account in which the FXP can holds funds, denominated in the IPS’s currency. (The FXP's account holds bank deposits, not central bank money.)
The SAP makes and receives payments on behalf of the FXP.
An FXP is able to combine both options, ie have direct membership in 1 IPS and indirect access in another IPS to facilitate an FX corridor. For each FXP, the choice of access model may differ depending on the country:
An FXP may not be eligible for membership of the IPS. In some countries, only banks (licensed credit institutions) are eligible to join the IPS, so non-bank PSPs who act as FXPs would need to use indirect access via an SAP. Other non-banks, such as non-bank FX dealers, are usually not eligible for access in any IPS.
An FXP may be eligible for IPS membership, but the cost of membership may outweigh the benefits. Typically IPS membership is geared towards institutions that will process significant volumes of domestic payments, and so there are significant requirements around the security and resilience of an IPS member’s technology and a lengthy onboarding process. However, for Nexus an FXP only really needs the ability to hold funds in that IPS. If they do not intend to process significant volumes of domestic payments on behalf of customers in a specific country, the costs of becoming a member of that country's IPS may be prohibitive. In this case, it would be easier and cheaper for the FXP to use an SAP.
An FX Provider is likely to use direct access to an IPS for countries where they are already established (for example as a domestic PSP), and indirect access for other countries.
In the diagram below, FXP-A is a major international bank. It is a member of both the Source and Destination IPSs, as it has a significant presence in both those countries. It can accept funds in the Source IPS and pay out funds in the Destination IPS (and vice versa for payments in the opposite direction). It therefore acts as an SAP to itself in both the Source and Destination Countries. The obligations that apply to SAPs (as defined in the Nexus Scheme Rulebook) also apply to FXP-A.
FXP-B is a regional bank. It is a member of the Source IPS, in the country where it is headquartered and so acts as Source SAP to itself. It does not have a significant presence in the Destination Country, so cannot justify the expense of joining the Destination IPS. Instead, it uses an SAP to get access to the Destination IPS. The obligations that apply to SAPs (as defined in the Nexus Scheme Rulebook) also apply to FXP-B.
FXP-C is a non-bank FX dealer, and therefore not eligible for access to any IPS. It uses SAPs for every IPS that it wishes to access. It must comply with the obligations upon FXPs, but not the obligations for SAPs.
The Nexus Scheme Rulebook provides detailed obligations for FX Providers. At a high level, these obligations include:
FX Providers must comply with all applicable regulations in the jurisdiction they are based in, as well as the jurisdiction to which they are providing FX.
FXPs must commit to providing FX to Nexus for a certain minimum duration and must give a period of notice if they wish to stop providing FX.
FXPs may choose to permanently withdraw from providing FX to Nexus.
The scheme rulebook and governance documents define the process and notice period for withdrawing from the scheme.
In general, FX Providers are expected to play a similar role to that of a market maker; this means that they are obliged to always provide a quote for the payment corridors that they provide. If they do not wish to be committed for new payments, they can set a quote that is below the rest of the market, but they should not “exit the market” by providing no quote at all.
This requirement is necessary to ensure that there is always liquidity available for Nexus payments and to avoid a situation where all FX Providers for a currency channel choose to “sit out” of the market (making payments through that channel impossible). The obligation to always quote also helps to ensure that FX rates will be dynamic and are likely to be broadly in line with other FX markets.
An exception may need to be made for FXPs who do not have the technical capacity to quote 24/7. For example, some FXP who do not have a global presence may only be able to quote in their country’s business hours. In this case, they would be expected to always provide active rates during their business hours but would be able to “exit” the market by withdrawing all their rates at the end of the business day. Over time and as they gain experience with Nexus payment flows, such FXPs should be able to develop the ability to automate rate provision and liquidity management outside of business hours, in order to start quoting 24/5 and ultimately 24/7.
There will be certain cases where Nexus payments must be reversed at a later date. The FXP must accept reversals at the exchange rate that was used in the original payment. This means the FXP takes the risk that market rates may have moved since then, and the FXP may take a profit or loss as a result of the reversal. The number of reversals to be small or negligible relative to overall payment flows, and gains and losses due to reversals should average out to zero over a given time period.
the FXP already holds a settlement account at the IPS, which is currently used for processing domestic instant payments. They act as a (SAP) to themselves
The IPS member providing the account to the FXP plays the role of to the FX Provider.
Where an FXP is a member of an IPS and therefore acts as their own Settlement Account Provider, the FXP is responsible for screening the payment against applicable sanctions lists. See for more detail.
FXPs are not permitted to charge a separate fee to PSPs for the FX service they provide. Therefore FXPs must set exchange rates at a level that provides for all their own costs plus a profit margin.
Key costs incurred by FX Providers will include:
The costs of acquiring a particular currency
The costs charged by Settlement Account Providers, where used (ie. in countries where the FXP is not itself a direct member of a particular Instant Payment System).
All other costs of operation, onboarding PSPs regulatory compliance etc.
For a specific Nexus payment, the FXP is effectively trading with the Source PSP by selling them the Destination Currency. This means the Source PSP is a corporate customer of the FXP. The FXP therefore has a regulatory obligation to complete due diligence (Know Your Business, KYB) on a PSP before it can provide FX conversion to that PSP.
A PSP can only select quotes from FXPs with which it has completed the due diligence process.
Once the FXP has completed due diligence on a PSP, it should inform Nexus (via the Nexus administration portal or Nexus APIs) that it is willing to provide FX to that PSP. When generating quotes in response to the GET /quotes/
API, Nexus will only provide quote IDs for the FXPs that have approved the PSP.
(Nexus will include rates from other FXPs so that PSPs can see if other FXPs offer better rates; if so, the PSP may choose to onboard with other FXPs.)
To ensure the FX market in Nexus is competitive, it is best if each PSP in an IPS is onboarded with each of the FXPs that provide FX in the PSP’s home currency. This means a PSP must apply to be onboarded with multiple FXPs, and each FXP must onboard multiple PSPs.
One challenge is that this due diligence can result in a large number of KYB processes with significant duplication of effort. The administrative cost of this process can:
discourage FXPs from onboarding smaller PSPs as the benefits of doing so (additional payment flows) may not outweigh the costs of the due diligence process
discourage PSPs from onboarding with multiple FXPs, as the benefit of doing so (more competitive rates) may not outweigh the costs of onboarding with additional FXPs
It is therefore important to streamline the PSP-FXP onboarding and due diligence process as Nexus scales. Possible measures to streamline this process (which would need to be explored further) include:
Mandatory use of the Wolfsberg Correspondent Banking Due Diligence Questionnaire (CBBDQ). This is a standard questionnaire that can be used for due diligence by FXPs on PSPs (and by SAPs on FXPs). It ensures that a PSP only needs to complete the questionnaire once (and keep it up to date), rather than dealing with a bespoke application form for every FXP. From the FXP's side, the questionnaire ensures that each PSP provides the same information in a consistent structure.
Possible digitalization of the process for a PSP to apply to onboard with an FXP, including the possibility of a repository for relevant information (such as the Wolfsberg Questionnaire, incorporation docs) that can be accessed (with the PSP’s permission) by FXPs
The possibility for an FXP to see which other FXPs have already onboarded a specific PSP. This does not remove the need for the FXP to complete their own due diligence but may provide some degree of social proof for lesser-known PSPs, making it progressively easier for a PSP to complete the KYC process as a PSP becomes approved by a greater number of FXPs.
Nexus is designed to ensure a competitive FX market:
FX Providers are in competition with each other to provide the best exchange rates.
PSPs have free choice over which FXP they use (so long as they have completed the initial KYC and onboarding process with that FXP)
When an FXP posts a quote to Nexus, they are informed of the current leading market rate for that corridor (but not the FXP offering that rate), so they can assess whether the rates they offer are competitive against the market.
FXPs do not have the technical permissions to use the GET /quotes/
API and so are unable to see the full breakdown of rates offered by their competitors, as this is commercially sensitive data. FXPs who are also PSPs will have two separate sets of API credentials and must not share the information from the GET /quotes/
response between the payments and FX departments.
To have competitive pricing, there must be more than one FX Provider for a specific corridor. Without this, the sole FX Provider will have a monopoly on that corridor. Rates in a monopoly corridor will be less competitive, although users could switch to using other payment methods, so there is still some pressure on the FXP to offer rates broadly in line with the wider FX market.
Nexus is designed to enable a wide range of actors to play the role of FX Provider. For example, Nexus enables institutions who are not members of an IPS to access that IPS through Settlement Account Providers. This ensures that FX provision is not limited to the largest international banks (who are members of multiple IPSs). It also makes it more likely that there is FX provision for lesser-used or “exotic” corridors.
FX Providers are responsible for informing Nexus of the rates at which they are willing to swap one currency for another.
The FXP sends rates to the POST /rates/
API
A rate in Nexus describes the ‘going rate’ at which an FXP is willing to swap one currency for another.
The rate is not specific to a single transaction. FXPs are not asked to quote or bid on individual transactions. This means that when an FXP provides a rate to Nexus, they are effectively saying “Until further notice, for any Nexus payment, I’m willing to exchange Currency A for Currency B at exchange rate X”. “Further notice” is given when the FXP sends a revised rate.
The rate provided is the rate that the FX Provider charges to the Source PSP. The Source PSP could choose to mark up this rate before displaying it to the Sender.
A rate provided by an FXP continues to apply until the FXP sends a new rate to the POST /rates/
API.
A new rate causes older rates to immediately expire. Source PSPs who call the GET /quotes/
API are only shown the most recent rates.
Rates can be updated as frequently or infrequently as the FX Provider wishes. Updates could be on a regular or irregular schedule. For example an FXP may choose to update their rates every minute, every half hour, every day or only when market conditions change significantly.
To manage load on the Nexus network, Nexus may apply an upper limit to how frequently rates can be updated. For example, given the lower values of Nexus payments compared to wholesale FX markets, there is little need to update rates multiple times a second (as happens in some wholesale FX markets), as any changes would made a negligible difference to the ultimate cost to the Sender. On the other hand, very frequent updates, multiplied across multiple corridors and multiple FXPs, could have a detrimental impact on the performance of the Nexus FX Service with very little end-user benefit.
Within the Nexus FX service, each rate contains the following information.
A rate is unique to:
A specific FXP, AND
A specific Source Instant Payment System (IPS), AND
A specific Destination IPS
Note that each rate is:
one-directional: a rate describes the rate of exchange for payments flowing in one direction only (eg from currency A>B).
independent & non-reciprocal: for a specific FXP, given currencies A & B, the rate for payments from B>A is set independently of the rate for payments from A>B. The rate for B>A is not simply the reciprocal of the rate for payments from A>B (eg 1 / (B>A)).
WORKED EXAMPLE: Asymmetric rates
FXP-A may wish to reduce their holdings of SGD and increase their holding of EUR. FXP-A provides two independent rates to Nexus:
EUR->SGD = 1.5000 (EUR 1 = SGD 1.50)
SGD->EUR = 0.6500 (SGD 1 = EUR 0.65, equivalent to SGD1 = EUR)
Note that the SGD>EUR rate is not simply 1 divided by the EUR>SGD rate, which would be SGD 0.6667.
The rates above may be attractive rate for anyone sending payments from the Eurozone to Singapore, but unattractive for anyone sending payments from Singapore to the Eurozone. This means the FXP is likely to be selected for payments from the Eurozone to Singapore, but unlikely to be selected for payments from Singapore to the Eurozone. Consequently, they are likely to accumulate EUR and run down their holdings of SGD.
In some cases, an FXP may need to ‘withdraw’ a specific rate. One example would be where the FXP needs to do maintenance on their own systems, making it impossible for them to manage liquidity for Nexus payments. In this case, an FXP could withdraw a rate using the DELETE /rates/
API. “Deleting” a rate would set this rate to expire so that it is no longer shown to PSPs.
This functionality has not been built as part of the PoC and would need to be added to a production version.
IPSs allow payments to be made 24 hours per day, seven days per week. In contrast, FX markets, where financial institutions buy and sell currencies from each other, are only open during business hours from Monday-Friday. Because of the global nature of FX markets, it is usually possible to trade major currencies for 24 hours a day from Monday to Friday, but not over the weekend. This means that there is no “live” market to define FX rates on Saturday and Sunday.
To enable Nexus payments at weekends, FX Providers must continue to provide FX over the weekend. There are two ways they could do this:
An FXP can update their rates when the FX markets close on Friday, and leave those rates fixed throughout the weekend, since the market rates will not change. In this case, they would “price in” the risk that the rates in the wider FX market on Monday morning may jump relative to the rates when the market closed on Friday evening. This means that the rates charged over the weekend are likely to be less competitive than those during the week, to cover this risk.
Alternatively, the FXP could continue to update its rates through the weekend. Although the market rates would not change, an FXP may wish to do this to manage their liquidity in the different currencies. For example, they can make their rates better or worse, compared to the market, in order to attract more or less of certain currencies.
ELEMENT
USAGE
EXAMPLES
Id
Autogenerated Id for this rate (a specific rate for a specific currency pair issued by a specific FXP at a specific time)
302293
FXP Id
Internal Nexus ID for the FXP (not external ID such as BIC or LEI, which is used in the API requests and responses)
1301
UnitCcy
ISO 20022 term for Source Currency
EUR
QtdCcy
ISO 20022 term for Destination Currency
SGD
Threshold
Minimum transaction size IN SOURCE CURRENCY at which the improvement applies. If the FXP has defined tiers for this Source Currency, the POST /rates/ API will generate additional improved rates based on those tiers.
10,000
Rate
Exchange rate, where UnitCcy Amount * Rate = QtyCcy Amount
1.5019
Source UPS
The Source Instant Payment System in which the FXP can receive the Source Currency.
EURTIPS
Destination UPS
The Destination Instant Payment System in which the FXP can receive the Destination Currency.
SGDFAST
DateTimeIssued
DateTime at which the Nexus Gateway accepts the quote and publishes it to the rest of the network
2022-09-11 15:52:23
DateTimeExpired
Initially blank. Will be set if an FXP withdraws their rates.
2022-09-11 16:52:23
FX Providers may also want to offer better rates to specific PSPs, for example, PSPs that already have a strong business relationship with the FXP. In Nexus this works as follows:
An FXP can define the PSPs to which it wishes to offer improved rates
For each PSP, the FXP can define how much the base rate should be improved, in basis points.
When a Source PSP calls the GET /quotes/
API, Nexus will check whether any FXPs have registered preferential rates for that PSP and apply the improvement to the FXP's base rate.
An FXP does not need to set any PSP-based improvements. If no PSP-based improvement is set for a specific PSP, the base rate will apply.
Quotes are generated in response to a specific quote request from a specific PSP. Quotes specify the rate available to the Source PSP after any tier-based or PSP-based improvements have been applied.
First the Source PSP calls the GET /quotes/
API, specifying the source and destination currencies and the value of the payment.
Nexus will then:
retrieve the rates for the currency pair requested by the PSP
for each FXP providing a rate:
Apply tier-based improvements: Nexus will check whether the transaction value is higher than any of the tiers set by FXPs for that currency. If it is, Nexus will apply the improvement to the relevant FXP's base rate
Apply PSP-based improvements: Nexus will check whether the FXP has registered a PSP-based improvement for the requesting PSP. If so, Nexus will apply the PSP-based improvements to the relevant rate (after any tier-based improvements have been applied).
return the full list of quotes with rates that have already been improved for both tier-based and PSP-improvements.
Every quote includes a quote ID which is unique to the PSP's quote request. The usage of this quote ID is explained below.
The Source PSP will:
Select their preferred quote from the list of quotes provided by Nexus. They may simply choose the best rate in the market or may choose a preferred FXP. (If the PSP is themselves an FXP, they may select their own quote.)
If the Sender approves the payment at that rate:
The PSP will call the GET /intermediaryAgents/
API to retrieve the relevant account numbers or bank identifiers of the FXP's SAPs. These will be used to fill the IntermediaryAgent
blocks of the pacs.008
payment instruction that the Source PSP will send to their local IPS
The quote ID will also be included in the pacs.008
, allowing Nexus to convert the amounts at the correct exchange rate.
A Sender of a payment would normally be shown the final FX rate (selected by the PSP, and possibly marked up by the PSP), before entering the details of the Recipient. To ensure a good user experience, we want the Sender to be able to complete the payment setup process without being asked to agree to a new, revised FX rate.
For this reason, FX Providers are obliged to honour a quote for exactly ten minutes (600 seconds) after it is provided to a Source PSP even if the FXP has since provided new rates.
Within the Nexus FX Service, every quote has an expiry time that is automatically set to 10 minutes after the quote is generated and returned to the Source PSP.
This 10-minute limit is intentionally set to be long enough for most Senders to be able to complete the payment setup process without having to refresh the agreed rate. The 10-minute limit is standard across all FXPs for Nexus.
FX Providers could be asked to honour quotes for a longer period of time, but this would result in them offering worse rates to allow for the greater risk of market FX rates changing before the sender completes the payment. Ten minutes is considered to be a fair trade-off between user experience for the Sender, and FX risk for the FXP.
For simplicity, in the following example there is only one FXP and two Senders.
Potentially
to the Sender
ELEMENT
USAGE
EXAMPLES
Id
Primary key of this PSP-based improvement, unique to a specific FXP and specific PSP
3289
FXP Id
Internal Nexus ID for the FXP (not external ID such as BIC or LEI, which is used in the API requests and responses)
1301
PSP Id
Internal Nexus ID for the PSP (not external ID such as BIC or LEI)
0592
Improvement
An improvement, recorded in basis points, which is applied to the rates after any tier-based improvements have been calculated.
30
DateTimeExpired
Initially blank. When the FXP issues a new Improvement for this PSP, the old one is set to expire.
FXP Id
PSP Id (this would be a BIC)
IMPROVEMENT in basis points (applied to the base rate in the FXP’s quote)
FXP-A
PSP-C
25
FXP-A
PSP-D
50
FXP-B
PSP-D
30
TIME | EVENT |
00m00s | Nexus receives and saves Rate 1 from FXP-A. |
01m00s | Nexus receives a quote request on behalf of Sender A. It generates a new Quote 1A. |
02m00s | Nexus receives a quote request on behalf of Sender B. It generates and replies with Quote 1B. |
02m01s | Nexus receives and saves a new Rate 2, from FXP-A. This overwrites Rate 1. |
02m30s | Nexus receives a quote request on behalf of Sender C. It generates and replies with Quote 2C |
09m30s | Nexus receives a payment instruction from Sender A referencing Quote 1A. Nexus checks the expiry time for Quote 1A. Since Quote 1A only expires at 11:01 (601 seconds after the quote was generated), this quote is still valid and can be honoured. |
12m30s | Nexus receives another payment instruction, this time from Sender B referencing Quote 1B. Quote 1B expired at 12:01 (02:00 + 601 seconds), so this quote is no longer valid. The Source PSP must request an up-to-date quote and show this to the Sender. |
Settlement Account Providers (SAPs) enable FX Providers who are not members of a particular instant payment system (IPS) to participate in Nexus.
SAPs provide accounts to FX Providers (FPXs) who are not members of a particular Instant Payment System (IPS). This allows FXPs to provide FX to a wider range of corridors, without needing to become full members of each domestic IPS (which can be prohibitively costly). By providing this service, Settlement Account Providers play a crucial role in enabling efficient and competitive FX provision in the Nexus network.
Any PSP (ie member of an IPS) can act as an SAP if they choose, subject to the conditions and obligations outlined in this section.
Before reading this guide, please review the overview of the FX provision model in Nexus.
The SAP is only engaged at the point that a Source PSP has selected an FX Provider’s quote and submitted a payment instruction to the Source IPS referencing that quote. The payment instruction will reference the accounts that the FXP holds with SAPs.
NB: Where an FXP is a member of the IPS, they do not need to use a separate SAP. Instead, they effectively act as SAP to themselves (for that specific IPS). In this case, the FXP must also comply with the obligations that apply to SAPs and should also read this guide. The rest of this guide assumes that the FXP is not a member of the IPS and therefore uses a SAP in each IPS.
An SAP must be a member of at least 1 domestic IPS so that they are able to send and receive payments. Therefore, an entity must be a PSP (as defined in Nexus) in order to become an SAP. (All SAPs are PSPs by definition, but not all PSPs will choose to act as SAPs.)
The Settlement Account Provider only deals in its own “domestic” currency. It does not swap one currency for another and therefore is not an FX Provider (although it does provide services to the FX Provider).
Nexus does not select or appoint SAPs. An SAP must be chosen by an FXP.
The terms between the SAP and FXP are agreed bilaterally, outside of the Nexus scheme.
An FXP will select only one SAP per IPS. However, as multiple FXPs can provide FX to a specific currency pair, there may be multiple SAPs for a specific IPS.
One SAP can provide services to multiple FXPs.
An FXP can use different SAPs in different IPSs. (The Source SAP and Destination SAP do not need to be the same company, and do not need to have any relationship with each other or communicate with each during payment processing.)
Nexus processes payments from the Source PSP to the Destination PSP via two Instant Payment Systems (IPSs). The Nexus payment is settled in each IPS between the respective PSP and the SAP.
For a specific payment, a SAP will play one of two roles:
The Source Settlement Account Provider (S-SAP) is a member of the Source IPS. It provides an account to the FXP, denominated in the Source currency.
The Source PSP sends funds (in the Source Currency) to the FX Provider’s account at the S-SAP.
This payment is processed through the Source IPS, who debits the Source PSP and credits the Source SAP.
The Source SAP will in turn credit the FXP’s account.
The Destination Settlement Account Provider (D-SAP) is a member of the Destination IPS. It provides an account to the FXP denominated in the Destination currency.
The D-SAP will debit the FXP’s account at the D-SAP
The D-SAP will then send funds (in the Destination Currency) to the Destination PSP’s account
This payment is processed through the Destination IPS, who debits the D-SAP and credits the D-PSP
A more detailed explanation of this process is given in Flow of funds through Nexus.
FX Providers are responsible for managing their liquidity in various IPSs to ensure that payments from their Destination SAP (or from their own Destination IPS account if they are a member) can always be made.
Nexus assumes that FXPs who have active rates hold sufficient funds to honour payments.
Nexus will enable FXPs to manage their liquidity by informing FXPs immediately after each payment is processed.
When Nexus successfully processes a payment which references an FXP’s quote, Nexus will send a notification to the FX Provider. These notifications allow the FXP to update their internal records and monitor the balance of each of their accounts.
The FXP is responsible for processing these notifications in order to update their internal systems to keep track of their liquidity and taking any action as required to manage that liquidity.
It is the FXP's responsibility to ensure it manages its liquidity and ensure it is always able to process payments.
An FXP may be penalised if payments against their quotes fail because of a lack of liquidity in their account at a Settlement Account Provider (or their settlement account, if they are a member of the IPS). (A Destination SAP is likely to check the balance of the FXP’s account before approving or reject payments that reference the FXP’s quote.)
Each FXP must also ensure they have the liquidity to meet expected payment flows over the weekend, either in their own IPS accounts or at their Settlement Account Providers. This may require active or automated management of the level of funding in their settlement accounts. The FXP could also actively or automatically alter the rates offered by the FXP to alter the flow of payments that the FXP is selected for; this will have an impact on how their holdings of each currency increase or decrease. This is a matter for each FXP to manage individually.
In principle, the SAP acts as a provider to the FXP, by facilitating access to the IPS for that FXP. The commercial relationship between the SAP and the FXP sits outside of the scope of the Nexus Scheme and the specific pricing arrangements are to be arranged bilaterally between the FXP and SAP. However, note that the Nexus Scheme does set the following requirements:
The SAP is permitted to charge the FXP for the service it provides. This could include a fixed periodic fee for the provisioning of the account, as well as a per-transaction fee for the transactions settled by the SAP on behalf of the FXP. (As these transactions are settled in the domestic IPS, it would be in line with convention for the SAP to charge a flat transaction fee, not a percentage of the amount.)
The SAP could also supply the FXP with liquidity in the form of credit, for a charge.
The SAP is not allowed to deduct fees from the value of the payment transferred; it must pass on the funds in full. Any fees charged by the SAP to the FXP must therefore be charged separately and paid by the FXP to the SAP outside of the Nexus scheme.
The SAP will have to pay membership fees and likely per-transaction fees to the domestic IPS. These fees are set by the IPS and are not defined or standardised in the Nexus Scheme Rulebook.
The SAP will need to become a Participant in the Nexus Scheme and as such, is liable for a SAP-specific Nexus Scheme membership fee (if one exists). Any Scheme fees charged to SAPs will be set by the Nexus Scheme Organisation such as to cover the costs of the Nexus Scheme on a non-profit basis.
The SAP will need to apply sanction screening to payments it processes on behalf of the FXP.
The SAP will need to include these costs in its fees towards the FXP (although some of these costs, such as IPS membership fees, can be shared across other payment services, such as domestic payments).
In Nexus a specific FXP can offer better rates for larger transactions. This works as follows:
For each specific Source Currency, the FXP can define a number of “tiers” at which better rates apply.
For each tier, the FXP will define how much the base rate (as provided in the POST /rates/
API) should be improved, in basis points.
For payments smaller than the lowest tier, the base rate (provided in the POST /rates/
API) applies. (This is recorded in Nexus as a rate with a threshold of zero.)
Note:
An FXP can choose whether or not to set tiers for a specific currency, and how many tiers to set.
Different FXPs can set different thresholds for their tiers
After submitting a new tier or changing the rate on a tier, changes to an FXP's tiers will only be applied to newly submitted rates. Nexus will not retroactively apply changed rates to existing rates.
WORKED EXAMPLE - TIER IMPROVEMENTS
The Source Currency is Euros. The maximum payment permitted through the TIPS payment system is EUR 100,000. The FXP could therefore choose to set the following tiers:
This means that for a payment of 50,000, the rate will be improved by 1%, and so the amount received by the Recipient will be 1% greater than it would have been with the base rate.
If FXP-A quoted the base rate for EUR>SGD at 1.500, then the improvement would be calculated as:
Improved rate = Base Rate * (1 + (basis points / 10000)
= 1.5000 * (1 + (100 / 10000))
= 1.5000 * (1 + 0.01)
= 1.5000 * (1.01) = 1.5150
Note that for transactions below the 50,000 threshold, FXP-A’s base rate, as provided in the initial POST /rates/
API call, will apply.
ELEMENTS | USAGE | EXAMPLES |
Id | Autogenerated primary key of this tier, unique to a specific FXP, Source Currency and threshold (minimum amount) | 20515 |
FXP Id | Internal Nexus ID for the FXP (not external ID such as BIC or LEI, which is used in the API requests and responses) | 1301 |
UnitCcy | ISO 20022 term for Source Currency. Thresholds relate to value of the payment in this currency only (not Destination Currency) | EUR |
Threshold | Minimum transaction value IN SOURCE CURRENCY at which the improvement applies. The payment value must be equal-to-or-greater-than (>=) this threshold value. | 50,000.00 |
Improvement | An improvement, recorded in basis points, which is applied to the base rate. | 100.00 |
DateTimeExpired | Initially blank. Will be set when an FXP provides a new improvement for this threshold. |
FXP Id | SOURCE CURRENCY | TIER THRESHOLD (Minimum transaction size at which the improvement applies) | IMPROVEMENT in basis points (applied to the base rate in the FXP’s quote) |
FXP-A | EUR | 25,000 | 50 |
FXP-A | EUR | 50,000 | 100 |
FXP-A | EUR | 75,000 | 150 |
An SAP in Nexus can be any licensed financial institution that is:
A participant of a domestic that is a Nexus Scheme participant (and is therefore a PSP in Nexus terms)
Licensed by a national central bank or equivalent regulator, and regulated or supervised for safety, soundness and conduct.
Able to send and receive instant payments through the domestic IPS.
A SAP must have direct membership of the IPS; indirect, sponsored or technical access is not currently permitted.
Detailed eligibility criteria will be defined in the Nexus rulebook.
An SAP must sign an adherence agreement to become a direct member of the Nexus Scheme. The adherence agreement requires them to comply with the various obligations and responsibilities that apply to SAPs, as defined in the Nexus Scheme rulebook.
An SAP should first be registered with Nexus as a PSP. The SAP should then inform Nexus that it is willing to act as a SAP to a specific FX Provider(s).
The FX Provider (and not the SAP) has responsibility for informing Nexus of the SAP and specific accounts that it wishes to use for each IPS. (See FXP Onboarding with Nexus.)
As the SAP is sending and receiving payments on behalf of the FXP, the SAP is obliged to undertake due diligence upon the FXP. This could include standard Know Your Business checks as well as any local requirements.
Once the SAP has completed due diligence on an FXP, it should inform Nexus (via the IPS Operator) that it is willing to provide settlement account services to that FXP.
The number of FXP-SAP relationships in Nexus can be significant, especially as the network scales. This depends on the number of IPSs in the network, the number of FXPs, and how many of those FXPs use SAPs (rather than being an IPS member). It is therefore important to streamline the FXP-SAP onboarding and due diligence process as Nexus scales. The same measures that are used to streamline the PSP-FXP onboarding process can be used here – see Streamlining the Onboarding Process.
In particular, it is recommended that SAPs use and accept the Wolfsberg Correspondent Banking Due Diligence Questionnaire (CBDDQ) when onboarding FXPs.
The Instant Payment System Operator (IPSO) is responsible for:
processing Nexus payments between their member Payment Service Providers (PSPs) and Settlement Account Providers (SAPs).
managing the onboarding of PSPs and SAPs to Nexus
operating a local instance of the Nexus Gateway software, which handles cross-border coordination of payments between two Instant Payment Systems (IPSs)
keeping the reference data in the Nexus Gateway up to date
The Nexus Scheme Rulebook provides detailed obligations for Settlement Account Providers. At a high level, these obligations include:
Settlement Account Providers must be members of an IPS and therefore need to adhere to the local IPS system rules and admission criteria.
The SAP must sign the adherence agreement with its local IPS.
The SAP needs to onboard the FXP and comply with local laws and regulations, including (but not limited to) due diligence on the FXP. See the section on [Onboarding FXPs].
The SAP has total discretion over whether it offers services to a specific FXP or not, and on what terms. The terms of service between the SAP and FXP will be agreed bilaterally, outside of the Nexus Scheme.
The SAP must provide the FXP with an account denominated in the local currency, and the tooling to manage the balance on the account.
SAPs are obliged to ensure they have sufficient liquidity in the IPS at all times. SAPs need to take extra care in the case other payment streams, such as domestic payments, make use of the same liquidity.
It is best practice for the Destination SAP to check the balance of the FXP’s account before approving or reject payments that reference the FXP’s quote. An FXP may be penalized if payments against their quotes fail because of a lack of liquidity in their account at a Settlement Account Provider.
SAPs must comply with all applicable regulations in the jurisdiction they are based in.
The SAP must confirm that all payments the SAP receives through Nexus will be screened against the sanctions lists applicable in the SAP’s jurisdiction (and that the SAP will apply with any other regulations and laws applicable in the SAP’s jurisdiction).
The SAP also must have real-time sanctions screening ability.
The SAP must ensure the SAP’s internal systems can handle and process the Nexus pacs.008, which may be more data-rich than the domestic format.
The SAP must undertake a robust testing process with the IPS Operator and FXP to ensure that all systems are working as expected before go-live and before any significant change.
Where an FXP is a member of an IPS and therefore acts as their own Settlement Account Provider, the FXP is responsible for screening the payment against applicable sanctions list, as per any SAP.
SAPs must commit to providing services to an FXP for a certain minimum duration (to be defined in the Nexus Scheme Rulebook) and must give a period of notice if they wish to stop providing those services. This is to avoid unexpected disruption to Nexus payments, which could occur if a SAP withdrew its services at short notice.
There will be certain cases where Nexus payments must be reversed at a later date. The SAP must allow these reversals to be made. The number of reversals is expected to be small or negligible relative to overall payment flows.
The following obligations will be taken care of by Nexus:
Notifications to FXPs: Nexus will update the FXP after each transaction with an fxtr.017 message, so the SAP does not need to update them of changes to balances in real time (but can do, in addition).
To understand how payments are processed in Nexus, please see the Flow of funds in Nexus and Detailed messaging and processing. SAPs should pay special attention to two points:
When acting as Source SAP for a specific payment, the SAP should:
Screen the Sender and Recipient of the payment against the sanctions lists applicable in the SAP’s jurisdiction.
Accept (or reject) the payment as they would a normal domestic payment.
When acting as the Destination SAP, the payment is noticeably different from a domestic payment:
The Destination SAP will receive a Nexus pacs.008 payment instruction from the Destination IPS. The D-SAP must:
review this pacs.008, confirm that the FXP’s account (specified in the pacs.008) has sufficient funds, and
screen the Sender and Recipient against the sanctions lists that apply in the D-SAP’s jurisdiction.
If the D-SAP is happy to proceed, it must submit the pacs.008 to the D-IPS (in the same way it would submit a domestic payment instruction)
If the D-SAP is not happy to proceed, it should respond to the D-IPS with a pacs.002 with a RJCT status code to confirm that the payment will not be processed. (The D-IPS will then communicate with Nexus to reverse the payment.)
Each SAP must:
Screen the Sender and Receiver against the sanctions lists applicable in the SAP‘s jurisdiction.
If the SAP receives a positive match against the sanctions lists, they may use the Request-for-Information [LINK TO SECTION] process to request further information from the Source PSP or Destination PSP.
They can use any additional information provided to re-screen or to confirm whether the initial hit was a true or false positive.
In the case of a true positive match, the SAP should reject the payment with a pacs.002 with a RJCT status code.
In the case that no further information is available, the SAP must decide whether to accept or reject the payment and should confirm their decision to Nexus through the pacs.002 message. (Unlike Destination PSPs, SAPs are currently not permitted to take extra time to complete sanctions screening.)
In the case of no match or a false positive match, the SAP should accept the payment by returning the Nexus pacs.002 message with an ACCC status code.
PSPs that don’t support real-time sanctions screening, are not able to act as SAPs (because they will introduce delays into every payment).
It is the FXP's responsibility to ensure it manages its liquidity and ensure it is always able to process payments. Nexus assumes that FXPs who have active rates hold sufficient funds to honour payments against those rates.
SAPs are responsible for managing their own liquidity in the IPS to ensure that payments on behalf of their client FXPs can always be made.
Nexus will support FXPs to manage their liquidity by informing FXPs immediately after each payment is processed.
When Nexus successfully processes a payment which references an FXP’s quote, Nexus will send a notification to the FX Provider. These notifications allow the FXP to update their internal records and monitor the balance of each of their accounts. (See [FX GUIDE – FXTR17 NOTIFICIATIONS] for further detail.)
The FXP is responsible for processing these notifications in order to update their internal systems to keep track of their liquidity and taking any action as required to manage that liquidity.
An FXP may be penalized if payments against their quotes fail because of a lack of liquidity in their account at a Settlement Account Provider (or their settlement account, if they are a member of the IPS). It is best practice for a Destination SAP is likely to check the balance of the FXP’s account before approving or reject payments that reference the FXP’s quote.
As Nexus payments can be made 24/7, including weekends, SAPs must ensure that their liquidity management considers payment flows that may occur out of normal business hours.
The IPSO can then start to onboard its own members onto Nexus. The scheme adherence process differs depending on the role an IPS Member wishes to play:
Payment Service Providers (PSPs) – in Nexus the term “PSP” is used inclusively to refer to all banks or non-bank payment service provides which are eligible to be members of the IPS and to initiate and receive payments. Nexus does not set domestic eligibility requirements, so if non-bank PSPs are permitted to be members of a specific IPS, those non-bank PSPs are also eligible to join the Nexus Scheme.
PSPs adhere to the Nexus scheme indirectly, by signing an addendum to their existing adherence agreement with the IPS’s domestic payment scheme. This addendum should confirm that the PSP agrees to abide by the additional obligations upon PSPs who send and receive cross-border payments through Nexus. These obligations are defined in the Nexus Scheme Rulebook.
The signing of this addendum must be managed by the IPSO.
Settlement Account Providers (SAPs) adhere to the Nexus scheme directly. An entity must be an IPS Member (and therefore a PSP) before it can start acting as a SAP in Nexus. Therefore a SAP must sign:
The addendum to the IPS’s domestic scheme, relating to its responsibilities as a PSP sending and receiving payments on behalf of its customers. This must be managed by the IPSO.
The Nexus Scheme adherence agreement, relating to its additional responsibilities as an SAP. This will be managed by the Nexus Scheme Organisation
FXPs adhere to the Nexus scheme directly. An FXP may be a member of an IPS, in which case they can act as SAP to themselves. If the FXP is not a member of the IPS, the FXP can open accounts with SAPs through which they can send and receive payments via that IPS. FXPs therefore have a range of responsibilities outside payment processing, and so adhere directly to the Nexus scheme.
If an FXP is a member of an IPS, the FXP must sign that IPS’s addendum to become a PSP that participates in Nexus
If an FXP is not a member of any IPS, it will only interact with the Nexus Scheme Organisation to sign the Nexus Scheme adherence agreement.
An FXP can connect to the Nexus Gateway that is most convenient.
The Nexus Gateway is a software component which coordinates processes such as cross-border proxy resolution, FX quoting and conversion, messaging, the sequencing of payments between two countries and the reversal of failed payments.
Each IPSO will install and run their own instance of the Nexus Gateway software. Each Gateway connects to the domestic IPS infrastructure on one side and to Nexus Gateways in other countries on the other side.
An IPSO must provide the Nexus Gateway with certain reference data. This information can be provided via:
The browser-based administration portal
The Nexus APIs (using credentials with appropriate permissions for the IPSO)
The reference data includes:
The Unique Payment Systems (a unique combination of an IPS and a currency) that this IPSO is responsible for
The permitted addressing formats for this IPS (such as IBAN and/or local account formats and financial institution identifier formats)
Any proxy (alias) schemes available in the IPS’s jurisdiction (to which Nexus participants can connect), and the proxy formats that they support (eg email, phone number)
All member PSPs in the IPSO, including those that are not onboarded with Nexus, and whether each PSP is onboarded with Nexus or not.
Where this data is required by other Nexus participants (eg PSPs in other countries) the local Nexus Gateway will automatically synchronise this data to all Nexus Gateways. (In practice, most reference data is synchronised to every other Gateway, although some data points are only required for internal processing.)
There are two models for a PSP to communicate with the Nexus Gateway, depending on the local IPS implementation:
Via the IPS: All communication will go through the existing secure connection between the PSP and the IPS. The IPS can provide pass-through APIs that forward requests to the local Nexus Gateway APIs (and vice versa).
Via a common shared network: Where a secure network exists between all PSPs and the IPSO, the IPSO may request PSPs communicate directly with the Nexus Gateway. In this case, the local Nexus Gateway would have its own identifier or address on the secured network.
Nexus Gateways will also support communication through message queues where this is used by the IPS and PSPs.
An FXP can connect to any Nexus Gateway. The FXP should choose the one most convenient for them and then consistently communicate with that chosen Gateway. Their choice could be based on jurisdiction, geographical location, membership of the same secure network, or any other consideration.
Upon instruction by the NSO, the IPSO should issue an FXP with API credentials to connect to that Gateway.
The Gateway will ensure that any data generated in response to the FXP’s API calls will be distributed to the appropriate Gateways in the Nexus network.
The Nexus expects the IPSO (as operator of the Nexus Gateway) to take on the responsibility for connecting the local Nexus Gateway to the domestic Proxy Lookup Service(s) (PLS) operator, particularly where:
The IPSO and the PLS Operator are the same entity, AND/OR
In the country where the IPSO provides payment services to, there is only one PLS operator
The Nexus Gateway will allow the IPSO to add API credentials for the Proxy Lookup Service Operator. The Gateway can then communicate directly with the PLS to make proxy resolution requests on behalf.
IPS Operators are typically run as not-for-profit utilities. They usually earn revenue from a mix of annual fees and per-transaction charges.
The Nexus Scheme would not dictate how each IPSO should charge its own participants (PSPs and SAPs) for the service the IPSO provides to them.
Since IPS Operators usually only process domestic payments, connecting to Nexus could allow them to increase the volume of payments that they process. Cross-border payments are more complex to process than domestic payments, so it would be expected for an IPS Operator to charge a higher per-transaction fee for a cross-border payment, and/or an additional annual fee for enabling the cross-border service for a PSP.
On the costs side, an IPSO would need to pay a membership fee and/or per-transaction fee to the entity that operates the Nexus network. They would also have to make some initial changes to their own system as they integrate to Nexus.
This section shows how funds flow through Nexus. This is a simplified example that excludes many details and IPS-specific variations. The detailed messaging and processing steps are covered in much more detail in the next section.
For this example, let’s assume Maria Rossi, in Italy, wants to send SGD150 to Wei Long in Singapore. The exchange rate from the FXP is exactly 1.500 so Maria will pay EUR100.
First, the Source PSP debits Maria’s account by EUR 100
The Source PSP sends the payment instruction to the IPS
The IPS processes this payment by:
Debiting the Source PSP by EUR 100, and
Crediting the Source SAP by EUR 100
(The Source SAP will now credit the account it holds for the FX Provider with EUR 100)
The Source IPS sends the payment instruction to the Source Nexus Gateway.
The Source Nexus Gateway looks up the original FX quote, applies the exchange rate, and forwards the instruction (now denominated in SGD) to the Destination Nexus Gateway
The Destination Nexus Gateway now forwards the instruction to the Destination IPS
The Destination IPS sends the instruction to the Destination SAP, who:
Checks the FX Provider’s account with the SAP holds sufficient funds
Debits the FX Provider’s account by SGD 150
The Destination SAP sends the instruction back to the Destination IPS
The Destination IPS sends the instruction to the Destination PSP, for review
If the Destination PSP is happy to accept the payment, they will send an acceptance message to the Destination IPS
The Destination IPS now processes the payment by:
Debiting the Destination SAP by SGD 150, and
Crediting the Destination PSP by SGD 150
The Destination PSP can now:
Credit the Recipient’s account with SGD 150, and
Notify the Recipient that they have received a payment
The end result of this transaction is:
The Sender has paid out EUR 100
The Source PSP has paid EUR 100 to the Source SAP
The Destination SAP has paid SGD 150 to the Destination PSP
The Recipient has received SGD 150
The FXP has received EUR 100 in their account at the Source SAP, and paid out SGD 150 from their account at the Destination SAP. (So the FXP has exchanged EUR 100 for SGD 150.)
This chapter describes how a Nexus payment is processed across two instant payment systems (IPS). We start with a description of the typical payment process for a domestic payment, before building up to a full explanation of how Nexus payments would work across two independent IPSs.
To understanding the Nexus payment sequence, it’s helpful to start with the typical 5-message process typically used within an IPS for a domestic payment:
The Source PSP sends a payment instruction (usually ISO 20022 message pacs.008
) to the IPS (Message 2)
The IPS forwards the payment instruction (pacs.008
) to the Destination PSP who is also a member of the IPS (Message 3)
The Destination PSP reviews the payment instruction. If it is happy to accept the payment on behalf of the Recipient, it will confirm by responding to the IPS with a payment status message (ISO 20022 message pacs.002
) (Message 4)
The IPS will then process a payment from the Source PSP to the Destination PSP by:
debiting the Source PSP, and
simultaneously crediting the Destination PSP
The IPS sends a confirmation (pacs.002
) of the successful transfer to the Destination PSP (Message 5a)
The Destination PSP will credit the recipient and notify them (Message 7)
The IPS sends a confirmation (pacs.002
) of the successful transfer to the Source PSP (Message 5b)
The Source PSP will notify the Sender that the payment has been successful.
In instant payment systems, this process typically takes a few seconds.
IPSs typically follow one of two settlement models:
Immediate settlement in central bank money, in which individual transactions are processed by immediately transferring central bank money between IPS members.
This model is also known as real-time gross settlement, but may be a distinct platform from the “RTGS” platforms commonly used for larger and wholesale payments between financial institutions.
Examples of IPSs that use real-time gross settlement include TIPS in the Eurosystem, Brazil’s PIX, and Australia’s New Payments Platform (NPP)
Deferred Net Settlement, in which:
individual transactions are processed immediately, creating obligations between the IPS members
on a pre-determined schedule, the gross flows between IPS Members are netted, and the net differences are settled by a transfer of central bank money across accounts at the central bank
Examples of IPSs that use Deferred Net Settlement include Singapore’s FAST, Malaysia's RPP and the UK’s Faster Payments Service.
Step 4 above differs slightly depending on the settlement model used in the IPS.
If the IPS uses a real-time gross model, step 4 triggers the immediate transfer of funds between accounts at the central bank:
The Source PSP’s settlement account at the central bank is debited
The Destination PSP’s settlement account at the central bank is credited
Settlement is therefore immediate (real-time) and there is no netting of obligations (so the gross value of the transaction is settled).
In contrast, in a Deferred Net Settlement (DNS) model, settlement takes place at a later time (ie it is deferred). This works as follows:
Message 4 triggers a debit/credit operation which creates a record of an obligation from the Source PSP to the Destination PSP. Every other payment creates similar obligations.
At pre-set times each day, the IPS will net this obligation against the obligations created by many other payments, and will calculate the net obligation that each PSP must pay. This obligation might be positive (the PSP owes money to other PSPs) or negative (the PSP is owed money).
These net obligations are then settled through transfers between settlement accounts at the central bank.
Nexus is designed to be compatible with both DNS and real-time gross settlement models, although there are some variations that are addressed below.
The challenge for Nexus is to achieve the same outcome – a near-instant transfer from the Sender’s account to the Recipient’s account – when:
The Source PSP and the Destination PSP are in different countries
The Source PSP is not a member of the IPS in the Recipient’s country (the Destination IPS), and the Destination PSP is not a member of the IPS in the Sender’s country (the Source IPS)
The Source IPS and Destination IPS operate in different currencies
The Source PSP does not hold the Recipient’s currency, and the Destination PSP will not accept the Sender’s currency
To make a transfer between PSP-A and PSP-B work, we need to add two key elements:
A system that allows communication and coordination between the Source IPS and Destination IPS – this is facilitated by Nexus, through the Nexus Gateways
A party who is willing and able to accept the Sender’s currency in exchange for paying out the Recipient’s currency. This is the FX Provider (FXP)
The FX Provider must be able to send and receive payments in both the Source IPS and Destination IPS
The FXP will receive funds from the Source PSP via the Source IPS
The FXP will pay out funds to the Destination PSP via the Destination IPS
For the examples below, we will assume that the FXP is not a member of either IPS and so uses an SAP in the Source IPS (the Source SAP) and an SAP in the Destination IPS (the Destination SAP).
We can now identify all the parties involved in processing a Nexus payment:
The Source PSP, who initiates the payment on behalf of the Sender (their customer)
The Source Settlement Account Provider (S-SAP), which holds an account on behalf of the FXP (their customer) and accepts funds in the source currency into that account
The Source IPS, who is responsible for processing the payment between the Source PSP and Source SAP
The Destination PSP, who holds an account on behalf of the Recipient (its customer)
The Destination Settlement Account Provider (D-SAP), which hold an account on behalf of the FXP (its customer) and pays out funds from that account to the Destination PSP
The Destination IPS, which is responsible for processing the payment from the Destination SAP to the Destination PSP.
The Nexus Gateways in both the Source and Destination countries. These Gateways handle cross-border communication and transformation of some messages as they pass from one IPS to another
The FX Provider. However, although the FXP provides its rates to Nexus earlier, the FXP itself is not part of the communication chain when a Nexus payment is processed. (This is because the S-SAP and D-SAP can assume that if they receive a Nexus payment instruction, the instruction will be (or has already been) validated against the quote provided by the FXP, and that if validation of the quote fails, the payment will be immediately reversed.
Readers who are familiar with domestic IPS settlement methods (including deferred net settlement and real time gross settlement) may wish to skip to or .
The FXP may be a member of both IPSs. However, if they are not, they can open accounts with a PSP that is already a member of the IPS; this PSP then acts as Settlement Account Provider (SAP) to the FXP. For further details, please see .
The Nexus Scheme expects the IPSO (as operator of a Nexus Gateway) to take on the responsibility for connecting the local Nexus Gateway to the domestic proxy lookup service(s), particularly where:
The IPSO and the are the same entity, AND/OR
In each country that the IPSO provides payment services to, there is only one PLSO
Cases where there are multiple IPSOs or multiple Proxy Lookup Services in a particular country or jurisdiction may need to be handled differently. The approach to this scenario will be developed in a future phase of Nexus development.
IPSOs must adhere to the Nexus Scheme and become participants before they can process Nexus payments. However, the PLSO is not required (or able) to join the Nexus Scheme. Instead:
The IPSO must sign a bilateral agreement with the PLSO (or the scheme owner for the proxy lookup service, as appropriate)
This bilateral agreement must reflect the rules and obligations of the IPSO towards the PLSO and vice versa, as defined in the Nexus Scheme Rulebook, in order to ensure that the proxy lookup service is compliant with the Nexus Scheme.
The IPSO is responsible for verifying that the Proxy Lookup Service is compliant with the Nexus Scheme
Once an agreement is in place between the IPSO and the PLSO, the PLSO will provide the IPSO with API and security credentials that allow the Nexus Gateway to make proxy lookup requests on behalf of PSPs in other countries in the Nexus network.
Despite the detailed payment flow given earlier, Nexus is ultimately agnostic to domestic settlement processes, as long as the IPS can meet the specific requirements below.
The Source IPS must only send a pacs.008 payment instruction to the Source Nexus Gateway, if it can meet following requirements:
The Source IPS must have ensured that the funds from the Source PSP are secured. This means that if the Source PSP were to declare insolvency whilst the payment is being processed (or within the settlement cycle, in the case of deferred net settlement systems), the Source SAP must still receive the funds immediately or at the end of the settlement cycle.
Specifically, the funds in the Source IPS must be either:
Immediately transferred from the Source PSP’s settlement account to the Source SAP's settlement account (ie settled immediately in central bank money); OR
Reserved against the Source PSP’s account, so that they cannot be used for other purposes while the payment is being processed; OR
If a Deferred Net Settlement process is used, a pre-funding or collateral regime must ensure that even if the Source PSP were to be declared insolvent before the end of the settlement cycle, the Source SAP would still be paid in full in central bank money at the end of the settlement cycle.
The Source IPS must have the ability to reverse this payment in the case that the payment fails in the Destination IPS (for any reason). This means that the Source IPS must be able to move funds from the S-SAP back to the S-PSP. Again, the exact process will depend on the IPS in question.
The Destination IPS must only send a pacs.002 payment acceptance to the Source Nexus Gateway, if it can meet following requirements:
The Destination IPS must ensure that the funds from the Destination SAP are secured. As before, this means that if the D-SAP were to declare insolvency whilst the payment is being processed (or within the settlement cycle, in the case of deferred net settlement systems), the Destination PSP must still receive the funds immediately or at the end of the settlement cycle. As before, this assurance may be achieved in a number of different ways.
The Destination PSP must have responded with either:
ACCC status (the funds have been accepted and credited to the reciepient) or
ACWP status (the funds have been accepted by the Destination PSP but not yet credited to the Recipient. This may be used in the case that the Destination PSP has a sanctions hit for the Recipient, and needs further time to resolve the hit.)
The Destination IPS must have the ability to reverse the payment in case the Destination PSP is ultimately unable to credit the Recipient. This means the Destination IPS must be able to move funds from the Destination PSP back to the D-SAP.
Assuming that all of the requirements above are met, the role of Nexus is quite simple:
Nexus will wait to receive a pacs.008 payment instruction from the Source IPS
When it receives this, it assumes that the funds are secured and that the payment can be reversed if necessary
Nexus transforms this payment instruction and sends it to the Destination IPS, then waits for a pacs.002 response confirming whether the payment has been successful or not.
Proxy Lookup Service Operators (PLSOs) enable Nexus payments to be addressed using proxies (or aliases), such as mobile phone numbers, rather than account numbers.
Note: This guide assumes that each Instant Payment System has one – and only one – corresponding proxy lookup service. This is the case in most countries. However, in the euro area and the USA there may be multiple IPSs and multiple (often competing) proxy lookup services. This raises a number of complications that will be addressed in a future phase of development.
In many countries with instant payment systems (IPSs), payments can be addressed using “proxies” (or “aliases") in place of account numbers. A proxy (or alias) is any string of text that can be mapped to a specific bank account.
Commonly used examples include:
Mobile phone numbers
Email addresses
National ID numbers
Company incorporation numbers
Proxies are linked to existing accounts. Before a payment can be credited to the ultimate recipient, the proxy must be looked up and “mapped” to the corresponding account number. Multiple proxies could link to one account, but ideally a single unique proxy should only ever map to a single bank account.
This requirement is not always met. For example, where there are multiple competing proxy schemes in a country and no coordination between them, the same proxy (eg a phone number) could be registered in multiple schemes and linked to different accounts in each scheme.
Different countries have different formats of proxies as well as different levels of adoption. The table below shows some examples.
Nexus allows the use of proxies for cross-border payments. In principle, any proxy that is valid for domestic payments should also be valid for Nexus payments. (This is dependent on the relevant proxy service provider being onboarded and connected to Nexus.)
In Nexus, a proxy lookup request can be made by a customer of any PSP that is a participant in Nexus.
For Senders and Recipients of Nexus payments, the use of proxies improves the user experience:
Easier to share details: It is usually easier for the Recipient to share a phone number or email address than either (a) a bank identifier and account identifier, or (b) an International Bank Account Number (which can be 20-32 characters).
Reduce sharing of sensitive data: A payment can be addressed to the Recipient without the Recipient having to share sensitive account details (or even information about where they hold their accounts)
Provides confirmation of payee: Proxy lookup services typically provide some way of confirming the identity of the payee, for example, by returning the real verified name of the account holder (as provided by their PSP) or a nickname defined by the user. This helps to give the Sender confidence that they are sending funds to the correct account, as well providing a defense against fraud.
Nexus will not provide its own proxy service or proxy format; users cannot register with Nexus to create a global “Nexus ID’.
Proxy Lookup Service Operators (PLSOs) provide the databases which map proxies to specific Payment Service Providers (PSP, including banks) and accounts at that PSP.
PLSOs typically provide:
A database of proxies and associated PSP identifiers and account numbers / identifiers
A method for account holders to register and deregister proxies, or change the account linked to a specific proxy, via their authorized PSPs
A method for PSPs to make a lookup request to the proxy lookup service (ie sending a proxy and receiving back a PSP identifier, account number and name of the account holder)
In many (but not all) countries, the PLSO is the same entity as the Instant Payment System Operator (IPSO), and the instant payment scheme and proxy lookup scheme are managed by the same entity.
A simplified example of a proxy lookup database is below:
Proxy Lookup services are not available in all countries or payment communities. Whether or not a proxy service is available, Nexus still allows payments to be addressed using traditional account details, such as:
International Bank Account Number (IBAN), in countries that accept IBAN
Local PSP identifiers (such as BIC) and local account numbers
A country that does not have a proxy lookup service domestically is still permitted to send Nexus payments using the proxies available in the Destination Country.
COUNTRY
PROXY SCHEME
PROXIES
NOTES
Australia
PayId
Phone number
Registered business number
Addressing service provided by IPS operator (the New Payments Platform).
India
UPI
Mobile number
Virtual Payment Address (UPI ID),
Aadhaar ID (non-mandatory national identity number)
UPI ID has the format name@BankName or mobilenumber@BankName. Only the bank is able to map the name element to a specific account; the IPS operator does not have this information.
Malaysia
DuitNow
Mobile phone number
Business registration number
National ID number
The majority of account holders have linked their phone number to an account.
Singapore
PayNow
Mobile phone number
Unique Entity Number for corporations
National ID number
Virtual payment address
Significant adoption. Also used for payments from individuals to smaller businesses.
Sweden
Swish
Mobile phone number
High adoption: the majority of Swedish adults are registered with Swish
UK
PayM
Mobile phone number
Majority of account holders have not linked their phone number to an account via the PayM service. Service will be shut down in 2023 due to limited adoption.
PROXY
PROXY TYPE
ACCOUNT NAME
PSP IDENTIFIER
ACCOUNT IDENTIFIER
+6581234567
Mobile Phone (MBNO)
Wei Long
DBSSSGSG
2001009001
T09LL0001B
Corporate ID Number / Certificate of Incorporation Number (CINC)
Global Trading Pte Ltd
UOVBSGSG
3012929741
A number of events can cause the payment to be unsuccessful (aside from technical timeouts). For example:
The Source SAP, Destination SAP or Destination PSP applies sanctions screening and decides it does not want to process the payment, due to issues with either the Sender or the Recipient
The Source PSP may have insufficient funds in their IPS settlement account to make the payment
The Destination SAP checks that balance of the FXP’s account and finds it is insufficient to cover this payment
The Destination SAP’s own settlement account at the IPS has insufficient funds to make the payment to the Destination PSP
The Destination PSP finds that the Recipient’s account is closed, dormant or frozen
In the scenarios above, the participant that triggers the failure will send a pacs.002
with a status code of RJCT
(reject). This will flow back through the system and lead to the payment being reversed.
In a real-time gross system:
If reservations/locks were made against funds held by either the Source PSP or the Destination SAP, these reservations will be released/unlocked.
If funds have already been transferred between (a) the Source PSP and Source SAP OR (b) the Destination SAP and the Destination PSP, these transfers must be reversed.
In a Deferred Net Settlement system:
The record of obligation between (a) the Source PSP and Source SAP OR (b) the Destination SAP and the Destination PSP, must be cancelled or reversed.
When the PLSO is enabled through Nexus, the PLSO needs to fulfil the following obligations:
The PLSO should have the ability to process proxy lookup requests, with the required availability (in principle 24/7/365), and with business continuity arrangements.
The PLSO should verify, before a proxy is shared through Nexus, that the proxy is in control of the account holder (i.e. payee), or otherwise authorized by the possessor of the proxy to link it to the Recipient’s account. The PLSO guarantees that the proxy database will be kept current and changes made by proxy holders will be processed immediately.
The PLSO is obligated to verify that the account holder name provided by the service is accurate (for example, by only allowing changes to the name associated to the proxy to be made by the PSP providing that account, rather than by the person controlling the proxy itself).
The PLSO needs to ensure that all required consents have been collected for any information disclosed via Nexus. The method to do this should be compliant with local standards where the information is collected.
The PLSO will ensure that (contractual and implicit) privacy expectations of end users (both on the sending and receiving end of transactions) are met
The PLSO will keep track of queries processed for the purpose of providing an audit trail to relevant parties involved
The PLSO establishes a secure channel with the Nexus Gateway for the protection of sensitive data
PSPs have a number of obligations when using the proxy lookup service. These obligations are outlined in Obligations of PSPs.
As the proxy lookup service sits outside of the Nexus Scheme, the liability of either the IPSO or the PLSO must be agreed with in the bilateral contract between the IPSO and the PLSO. However, in general the following principles apply:
The PLSO shall not be liable for any failure, hindrance or delay in performance in whole or in part of its obligations if such failure, hindrance or delay arises out of circumstances beyond its control. Such circumstances may include, but are not limited to, acts of god, criminal action, fire, flood and unavailability of energy supplies
A cap on liability does not apply if there has been gross negligence by either the PLSO or the liable Nexus Participant or its employees or agents.
A cap on liability does not apply in the event of willful intent by either the PLSO or the liable Nexus Participant's employees or agents
The Nexus Scheme has no remit in disputes related to the local proxy lookup service.
If such a dispute between the Participants emerges, the parties shall use reasonable endeavors to solve the matter amicably. If the Participants fail to solve the dispute amicably, and the dispute affects other participants than the members of a single IPSO, the Nexus Scheme is to be notified by the IPSO and will be involved in the process of resolution of the dispute. The IPSO of the PLSO impacted by the incident will act as the coordinating party.
The responsibility to resolve the incident remains at the IPSOs and the PLSO, but the Nexus Scheme can act as a facilitator to the resolution process. The Nexus Scheme will assess whether the dispute has potential impact on the overall Nexus Scheme, and/or can occur in other Nexus links.
A PLSO may terminate its status as a PLSO by giving the agreed upon notice to is IPSO as part of the bilateral contract between the IPSO and the PLSO. However, this notice cannot be less than six (6) months.
As the PLSO is not a member of the Nexus Scheme, no scheme fees will be charged by Nexus towards the PLSO, and no fees will be charged by the PLSO to Nexus.
Any renumeration between the IPSO and the PLSO (in either direction) is subject to the bilateral agreement between the IPSO and the PLSO.
Nexus provides a collection of APIs that allow PSPs to communicate and send payments across borders.
The Nexus Gateway is a software component which enables Nexus payments. Each IPS in the Nexus network must operate a Gateway. Each Gateway connects to the domestic IPS infrastructure on one side and to Nexus Gateways in other countries on the other side.
Each participant will be issued API credentials by the IPSO, allowing them to connect to Nexus.
There are two models for a PSP to communicate with the Nexus Gateway, depending on the local IPS implementation:
Via the IPS: All communication will go through the existing secure connection between the PSP and the IPS. The IPS will provide pass-through APIs that forward requests to the local Nexus Gateway APIs (and vice versa).
Via a common shared network: Where a secure network exists between all PSPs and the IPSO, the IPSO may request PSPs communicate directly with the Nexus Gateway. In this case, the local Nexus Gateway would have its own identifier or address on the secured network.
Nexus Gateways will also support communication through message queues where this is used by the IPS and PSPs.
An FXP can connect to any Nexus Gateway. The FXP should choose the one most convenient for them and then consistently communicate with that chosen Gateway. Their choice could be based on jurisdiction, geographical location or any other consideration.
The Gateway will ensure that any data generated in response to the FXP’s API calls will be distributed to the appropriate Gateways in the Nexus network.
As SAPs are PSPs, they will connect to Nexus through the same mechanism as PSPs. As mentioned above, this may vary depending on the SAP.
The IPSOs can communicate with the local Nexus Gateway through APIs or message queuing.
Each IPSO will be responsible for arranging communication between the local Nexus Gateway and the proxy lookup service.
The PLSO must provide an API or a message queue endpoint at which it can receive proxy lookup requests from the Nexus Gateway. (These requests could be sent directly from the Nexus Gateway, or passed through via the local IPS, depending on the local network configuration.)
The PLSO must send proxy lookup responses to the Nexus Gateway API or endpoint as provided by the IPSO.
The PLSO must ensure necessary message security through eg API credentials, API secrets, hashing and message signing.
This section describes in detail the messages and processing required to achieve the flow of funds above.
We will give a typical payment flow through Nexus below, in detail. However, in practice Nexus is agnostic to exactly what happens within the domestic IPS, as long as the IPS can give two assurances:
the payment does not create unsecured credit risk between the Source PSP and S-SAP or between the D-SAP and Destination PSP, and
that the payment can be reversed if necessary.
These two requirements are described in more detail in Settlement and reversal requirements on IPSs.
The process can be split into distinct parts or “legs” – the Source Leg, the Nexus Leg and the Destination Leg.
Note that Nexus does not require:
Any changes to domestic settlement cycles; there is no need to synchronise settlement cycles between countries
Any awareness within the IPS of any currency other than the domestic currency. The IPS does not need to record balances or transfers in any other currency. (It only needs to ensure that the ISO 20022 payment message going through the IPS retain the necessary information to allow Nexus to manage the FX conversion.)
In the Source leg of the payment, the payment is processed in the Source IPS:
The Sender approves the payment
The Source PSP sends a payment instruction (ISO 20022 message pacs.008
) to the Source IPS (Message 2 in the diagram)
(In some real-time gross models, the IPS will now place a reservation or lock against the funds in the Source PSP’s account, so that those funds cannot be used for other payments.)
The Source IPS forwards the payment instruction (ISO 20022 message pacs.008
) to the Source SAP (who is also a member of the Source IPS) (Message 3)
The Source SAP reviews the payment instruction. As this is a cross-border payment, it must also apply sanctions screening. If it is happy to accept the payment on behalf of the FXP (its customer), it will respond with a payment status message (ISO 20022 message pacs.002) to confirming that it will accept the payment (Message 4)
The next step depends on the settlement model used in the IPS:
The Source IPS now recognises the payment as a Nexus payment, and forwards the original pacs.008
payment instruction message to the Source Nexus Gateway (Message 5).
Note: unlike a domestic payment, the Source IPS would not send a pacs.002
to the two PSPs yet. Instead, it waits to receive the response from Nexus.
Some IPSs may still choose to send a pacs.002 with a status code that informs the PSP that the payment has successfully been sent to Nexus. This would be at the discretion of the IPS and is not required or specified by Nexus.
The Source Nexus Gateway then validates and transforms the payment instruction to prepare it for the second leg by:
changing the instructing and instructed agents to the Destination SAP and Destination PSP respectively
validating the quote that is referenced, updating the currency and applying the currency conversion to the “Interbank Settlement Amount” (for example, validating the quote that is referenced in the message, converting the amount into the destination currency, and updating the instructed and instructing agents).
The Source Nexus Gateway then forwards the payment instruction to the Destination Nexus Gateway (Message 6).
The Destination Nexus Gateway immediately forwards the payment instruction to the Destination IPS (Message 7).
In the Destination Leg, the payment is processed by the Destination IPS:
(Note: in some real-time gross models, the Destination IPS will immediately place a reservation or lock on the funds in the Destination SAP’s account so that they cannot be used for other payments.)
The Destination IPS forwards the pacs.008
payment instruction message that it received from Nexus to the Destination Settlement Account Provider (D-SAP) (Message 8).
The Destination SAP confirms that the FX Provider has sufficient funds with them, and applies sanctions screening and compliance checks.
If the Destination SAP is happy to proceed with the payment, it will:
debit the FXP’s account with them by the amount of the payment, and
submit the pacs.008
payment instruction message to the Destination IPS (Message 9), effectively giving the IPS the instruction to forward the payment to the Destination PSP
The Destination IPS sends the pacs.008
payment instruction message to the Destination PSP (Message 10).
The Destination PSP will apply sanctions screening and compliance checks before deciding whether to accept the payment.
If the Destination PSP is happy to accept the payment they will then return a pacs.002
payment status message accepting the payment instruction (Message 11).
The next step depends on the settlement model used in the IPS:
The Destination IPS sends a confirmation (pacs.002
) of the successful transfer to the Destination SAP (Message 12a)
The Destination IPS sends a confirmation (ISO 20022 message pacs.002
) of the successful transfer to the Destination PSP (Message 12b)
The Destination PSP credits the Recipient’s account and informs the Recipient (9) that they have received funds. (Message 12c)
The Destination IPS then sends a pacs.002
acceptance message to the Destination Nexus Gateway to inform Nexus that Destination leg is complete (Message 13).
The Destination Nexus Gateway transforms the pacs.002
and forwards it to the Source Nexus Gateway (Message 14).
The Source Nexus Gateway forwards the message to the Source IPS (Message 15).
If the Source IPS uses a real-time gross settlement model and placed a reservation on the funds in bullet 1(a) above, they will now finalise the payment between the Source PSP and Source SAP by:
debiting the Source PSP’s settlement account at the central bank, and
simultaneously crediting the Source SAP’s settlement account at the central bank
The Source IPS will send the Source SAP a pacs.002
confirmation that the payment has been successful (Message 16a)
The Source IPS will send the Source PSP a pacs.002
confirmation that the payment has been successful (Message 16b)
The Source PSP can now inform their Sender that the payment is complete (Message 16c).
Finally, the Source Gateway informs the FXP that a payment has been processed using their quote (Message 17); this is important to enable the FXP to keep track of their liquidity.
(The FXP may also be separately updated of their account balances by the Source and Destination Settlement Account Providers.)
The Destination PSP is responsible for immediately crediting the Recipient with funds. In practice this means that the payment should be visible on the Recipient’s statement and the funds should be available for them to spend.
The Source PSP is responsible for immediately notifying the Sender that this payment was successfully completed. It is up to the Source PSP to choose how to do this, but the Sender should be able to establish with certainty that the payment is complete.
Once the PLSO has signed a bilateral agreement with the relevant IPSO, the PLSO must provide reference data to Nexus (via the IPSO).
This reference data defines the proxy lookup scheme and the proxy formats that it supports. The data will be provided to PSPs who are sending payments to the PLSO’s country. The PLSO is responsible for ensuring that the data is kept up to date.
For each proxy format, the following fields are defined:
The following codes are ExternalProxyAccountType1Code from the ISO 20022 External Code Set, available at www.iso20022.org. Commonly used proxy types are highlighted in bold.
A PLSO must use these codes when defining its scheme and when communicating with Nexus. If different codes are used domestically, it must map those codes to the list below.
Below is an example proxy scheme definition, in this case for the PayNow service in Singapore. Note only three of the proxy types used in PayNow are shown below.
Part of the Proxy and RFI Services. Used by PSPs.
The Sender may provide (a) a proxy, (b) a local PSP identifier and account number or (c) IBAN. These details can be sent to the POST/creditor/requests
API operation to retrieve the underlying account (in the case that a proxy is given) and additional information about the Creditor, where available:
If a proxy is provided, Nexus will first send it to the associated proxy lookup service in the Destination Country, as an acmt.023
message. The proxy look up service will return:
The PSP identifier (e.g. BIC) and account number
the real name associated with the account (in most cases), for use by the Source PSP
a display name that can be shown to the Sender
Nexus will use the PSP identifier to check that the Recipient’s PSP is Nexus-reachable (ie the Destination PSP must be technically enabled to receive Nexus payments and able to apply sanctions screening to incoming payments).
Nexus will then check whether the Destination PSP supports the Request For Information RFI message (camt.026
). If so, it will send a camt.026
to the Destination PSP to request verified information about the Recipient, so that the PSP does not have to ask the Sender to enter this information (which they may not know or may enter incorrectly). This feature is designed to improve the quality of data in the pacs.008
payment instruction, supporting automated sanctions screening and reducing the likelihood of the payment generating a false positive match against sanctions lists.
Nexus will send the full response to the Creditors request back to the Source PSP. The response will include the PSP identifier, the account number, the Recipient’s name, the Display Name of the recipient, and any further personal data on the Recipient that Nexus is able to retrieve from the Destination PSP’s response to an RFI.
We are reviewing whether acmt.023 (Identification Verification Request) would work in place of a full Request for Information flow (camt.026
) here, and will update this page accordingly.
When the Sender selects the Destination Country for a payment, the Source PSP will call the GET /proxyschemes/{countrycode}
API operation, specifying the country code. Nexus will respond with a full list of proxy schemes for that country (see example above).
Nexus will show the Sender a form allowing them to select one of the possible proxy types and enter the proxy details.
The Source PSP’s app must validate that the proxy details entered by the Sender is in the correct format. These validation rules will be provided as regular expressions in the proxy scheme definition provided by Nexus. The allows the PSP to validate the format in the app, without communication with Nexus or the proxy scheme.
Once the Sender has provided the proxy details, the Source PSP will use the POST /creditorrequests
API operation to send the information to Nexus.
The Nexus Gateway will send the data to the associated proxy lookup service in the Destination Country.
The proxy service will map the data and return any associated account details, or a negative response if the proxy is not linked.
Nexus will send a proxy lookup request to the PLSO formatted as an ISO 20022 acmt.023 (IdentificationVerificationRequestV03) message.
The PLSO must be able to accept the message in this format. If the domestic proxy lookup message format is different, the PLSO is responsible for translating the message from the Nexus acmt.023 to the domestic format message.
The Nexus acmt.023 has the following features:
The proxy provided by the Sender should be included in the Verification > PartyAndAccountIdentification > Proxy
element:
Type should include the ISO 20022 ExternalProxyAccountType1Code
(eg MBNO
) for the proxy type that was selected by the Sender
Identification should include the actual proxy text provided by the Sender
To allow the Proxy Lookup Service Operator to guard against phishing (eg entering phone numbers into a Nexus-enabled app in order to get the corresponding account holder names), the field Assignment > Creator > Party > Identification > Private Identification > Identification
should include a unique ID that uniquely identifies the Sender. This ID may be a official ID (eg National Identity Number) or a generated hash value that will be reused for all requests from this Sender. The PLSO can use this value to rate-limit the number of requests coming from a particular Sender.
The PLSO must respond to Nexus with an acmt.024
message. The PLSO is responsible for any translation required to convert from the domestic format to the Nexus acmt.024
.
If the proxy successfully maps to an account, the proxy lookup service should return, at a minimum:
the real name associated with the account (wherever possible) – this will be used by the Source PSP when sanctions screening the Recipient.
This should be in the element UpdatedPartyAndAccountIdentification > Party > Name
a display name that can be shown to the Sender to allow them to confirm the account holder is the intended Recipient
This could be the full name (where privacy and data protection rules allow this to be shown to the Sender), a partially obscured name or a nickname defined by the user, depending on the proxy service.
This value should be in the element UpdatedPartyAndAccountIdentification > Account > Name
(Note: this is a non-standard use of Account > Name, which should normally describe the name of the account rather than the account holder. Unfortunately the acmt.024
does not currently have a dedicated element for a display name that can be shown to the Sender but which may be different from the real account holder name.)
the PSP identifier (eg BIC) and account identifier of the linked account
Note that wherever possible, the full real name should be returned, as this information supports accurate and automated sanctions screening. Where the real name is not returned, the Source PSP must instead try to retrieve that information by (a) sending a Request for Information to the Destination PSP, although many PSPs will not support the RFI process, or (b) asking the Sender for this information, which may introduce inaccurate data, typos etc.
If the proxy is not registered or has been deactivated, the PSLO should respond with:
the /PrxyLkUpRspn/LkUpRspn/PrxyRspnSts/
element set to RJCT
the /PrxyLkUpRspn/LkUpRspn/PrxyRspnSts/StsRsnInf/Rsn/Cd/
element set to a valid ExternalStatusReason1Code from the ISO 20022 External Code Set (available at ISO20022.org). Typically only BE23
would be applicable:
The IPSO can use the Nexus administration portal to update information about the proxy lookup schemes. Alternatively the IPSO can use the relevant APIs to submit this information.
To set up a Nexus payment, the Sender must start by selecting the country the payment is going to (ie the Destination Country) from a drop-down list in the PSP’s app or online banking.
To populate this list, the PSP should retrieve the full list of Nexus countries and the currencies available in each country using the GET /countries/
API operation.
In most countries, only one national currency is used. However, some countries have payment systems that provide payments in 2 currencies – for example Hong Kong provides HKD and CNH payments. In this case, multiple currencies will be provided in the response to the GET /countries/
request.
Notes:
The response includes only those countries that are reachable via Nexus. It is not a complete list of all countries listed in the ISO 3166 standard.
In general, every country in the Nexus countries list should be included in the list shown to the Sender
If a specific country on the Nexus list is sanctioned by the PSP’s home jurisdiction, it is the PSP’s responsibility to remove that country from the list shown to the customer. Nexus does not store information on country-level sanctions rules and so cannot filter the list on behalf of the PSP.
The API does not return a country name. Instead, the two-letter country code must be mapped by the PSP to the full country name in the language(s) used in the PSP’s app or online banking channels
The countries list only changes when an Instant Payment System joins or leaves the Nexus network.
GET
https://local.nexus.gateway/api/v1/countries
Returns the list of countries that are connected to Nexus. Country codes are ISO-3166 alpha-2 country codes. Currencies are ISO 4217 alpha-3.
If the Destination PSP is not Nexus-reachable, the Creditors service will return an error explaining that the Destination PSP is not reachable via Nexus. (See ).
The following flow is described in more detail (with visual examples) in :
The following codes are from the ISO 20022 External Code Set, available at .
SETTLEMENT MODEL
ACTION
Deferred Net Settlement
Record an obligation from the Source PSP to the Source SAP by
debiting the Source PSP and
simultaneously crediting the Source SAP
Real-time Gross – Reservation Model
No action taken (because the funds are secured and the debit/credit action will only be done when the Destination Leg is complete).
Real Time Gross – No Reservation Model
Immediately transfer funds from the Source PSP to the Source SAP by:
debiting the Source PSP’s settlement account at the central bank, and
simultaneously crediting the Source SAP’s settlement account at the central bank
SETTLEMENT MODEL
ACTION
Deferred Net Settlement
Record an obligation from the Destination SAP to the Destination PSP by
debiting the Destination SAP and
simultaneously crediting the Destination PSP
Real-time gross – Reservation Model
Immediately transfer funds from the Destination SAP to the Destination PSP by:
debiting the Destination SAP’s settlement account at the central bank, and
simultaneously crediting the Destination PSP’s settlement account at the central bank
Real-time Gross – No Reservation Model
Same as for Real-time gross - Reservation Model
ELEMENT
FORMAT
USAGE
Scheme Name
Max35Text
Name of the proxy scheme
Effective Date
ISODateTime
Date when this version of the scheme definition takes effect (used to manage updates)
Operating Countries
List of ISO-3166 alpha-2 country codes
List of countries in which this proxy scheme is available
Proxy Formats
List of proxy formats – see table below
List of the different types of proxy used in this proxy scheme
ELEMENT
FORMAT
USAGE
Proxy Type
4 letters
The Proxy Type in Nexus is taken from the ISO 20022 External Code Set (available at www.iso20022.org) using the values from ExternalProxyAccountType1Code. The code can be mapped to a description in the language used in the PSP’s app. Current values are shown below, with the most commonly used types in bold.
Proxy Format
Regular expression
To be used for client-side validation in the PSP’s app or online banking services
Proxy Example
Text
Can be used as the “placeholder” element in a HTML form
Proxy Description
Text
Can be used as a tooltip or sub-label in the HTML form. An English-language description is mandatory, and other language descriptions can be defined. More specific description of the type of data required for this proxy type. For example, for a proxy type NIDN (National Identify Number) for Singapore, the description may include “NRIC/FIN” – two national identity number types).
PROXY TYPE CODE
TYPE OF PROXY
BIID
Biller Subscriber Identification
CINC
Certificate of Incorporation Number
COTX
Corporate Tax Identification
COID
Country Autonomy Identification
CUST
Customer identification Number
DNAM
Domain Name (Internet)
DRLC
Driver License Number
EIDN
Electronic Identification
EMAL
Email address
EWAL
E-Wallet identification
PVTX
Individual tax identification
LEIC
Legal Entity Identifier Code
MBNO
Mobile phone number
NIDN
National identification number
CCPT
Passport number
SHID
Scheme identification Number
SOSE
Social Security Number
TELE
Telephone Number (land line)
UBIL
Utilities Subscription Identification
VIPN
Vehicle Identification Plate Number
TOKN
Virtual payment addresses (treated as a “token”)
CODE | NAME | MEANING |
BE23 | AccountProxyInvalid | Phone number or email address, or any other proxy, used as the account proxy is unknown or invalid. |
Part of the Proxy Service. Used by PSPs.
When a Sender has selected the Destination Country, the PSP can use the GET /countries/{country_code}/proxyschemes
API operation to retrieve the list of proxy schemes and proxy formats available in that country.
GET
https://local.nexus.gateway/api/v1/countries/{countryCode}/proxyschemes
The GET /api/v1/countries/{country_code}/proxyschemes
response lists:
all proxy schemes available in the Destination Country and
the proxy formats available in each scheme.
The Proxy Type in Nexus is taken from the ISO 20022 External Code Set (available at www.iso20022.org) using the values from ExternalProxyAccountType1Code
. For commonly used proxy types, see
The ProxyType (PrxySchmes/PrxySchme/ProxyFmts/Prxy/PrxyTp
), and ProxyDescription (PrxySchmes/PrxySchme/PrxyFmts/Prxy/PrxyFmt
) fields can be used to automatically generate the addressing options form as shown below
When the Sender has selected a preferred address format, they should be shown the field to input a specific proxy.
If a proxy is selected, the PrxySchmes/PrxySchme/PrxyFmts/Prxy/PryExmpl
and PrxySchmes/PrxySchme/PrxyFmts/Prxy/PrxyFmt
elements can be used here:
Proxy Example = the example content shown in field before the user enters any information (ie the “placeholder” attribute on a HTML form element)
Proxy Format = the regular expression that can be used for client-side validation of the proxy provided by the Sender
If a local account number is selected, then the PSP will need to display a form that provides two input fields: one for the local PSP identifier (eg BIC) and one for the local account number.
The correct format for the PSP identifier is found in UPSs/UPS/PSPIdFmt
The correct format for the PSP identifier is found in UPSs/UPS/LclAcctId/LclAcctFmt
The provided proxy should be embedded in an acmt.023 message and submitted to Nexus using the POST /creditorrequests/
API operation. See Creditor Requests API for details.
The table below shows the action to be taken when the Creditor Info Request fails and what type of message could be shown to the Sender.
Part of the FX Service. Used by PSPs.
A Nexus payment flows through accounts held by an FX Provider in both the Source IPS and Destination IPS. These accounts need to be defined in the pacs.008
so that both IPSs know which accounts to debit and credit.
In the pacs.008,
ISO 20022 terminology is used:
Each Settlement Account Provider is defined as an Intermediary Agent
The FXP's account at the SAP is defined as an Intermediary Agent Account
For any specific quote, the Intermediary Agents (ie the FXP’s accounts) can be retrieved from Nexus by the GET /intermediaryagents/
API operation with the ID of the preferred quote:
GET
https://local.nexus.gateway/api/v1/intermediaryagents/
The response is automatically formatted in the structure required for the pacs.008 payment instruction that will be sent by the Source PSP to the Source IPS
The PSP can be identified using either BIC, LEI, or an alternative domestic format (“Other” in the ISO 20022 standard).
In case the BIC is used to identify financial institutions (Agents in the ISO 20022 standards), this may be either BIC 11 or BIC 8. Depending on the version of the ISO 20022 message used, the BIC of a financial institution may be populated either in a <BIC> or in a <BICFI> element (Note: the latter applies to the pacs.028.001.01, camt.027.001.06, camt.087.001.05 and camt.029.001.08 messages).
The Legal Entity Identifier (LEI) is a 20-character, alpha-numeric code based on the ISO 17442 standard developed by the International Organization for Standardization (ISO).
The Source PSP should provide its own LEI in the <LEI> element.
Where LEIs for other agents are available, they can also be used (but are not mandatory)
Domestic PSP identifiers need to follow the domestic formatting rules.
The format of domestic PSP identifiers should be defined using the Admin Portal, as a regular expression, so that it can be shared with Source PSPs when initiating payments to the Destination Country.
The Recipient can provide the Sender with the same account details that they would use to receive a domestic payment.
Account details vary in format from country to country, but typically include an account number and a series of numbers or letters that identifies the bank or branch which issues that account. Some examples of national account number formats are below.
Example Domestic Account Number Formats
In the version of Nexus developed in the PoC, we assumed that domestic accounts can be identified by just two pieces of information: an account number and a PSP identifier (such as BIC). This is not necessarily the case in all payment systems – for example, in some countries, three pieces of information may be required: bank identifier, branch identifier and account number. A production version of Nexus would need to be designed to accommodate such scenarios.
IBANs can be used to address Nexus payments when they are supported by the IPS and its member community. The Admin Portal can be used to confirm to Nexus whether IBANs are supported or not for a specific IPS.
In the case that IBANs are mandatory for all payments, the Admin Portal can be used to set the Domestic PSP Identifier Type to “None”.
Part of the FX Service. Used by PSPs.
As soon as Sender has selected the Destination Country for the payment and entered the Source Currency Amount or Destination Currency Amount, the PSP can call the Quotes
API.
Because some countries have instant payment systems that operate in more than one currency, both the currencies and the countries must be specified in the API call.
The PSP must also specify (using the amt
and amtCcy
query parameters) either:
The Source Currency Amount that should be debited from the Sender’s account, or
The Destination Currency Amount that should be credited to the Recipient’s account
The PSP should also provide their PSP Id (typically BIC) so that Nexus can calculate if each FXP provides any discount (PSP-based improvement) for that PSP.
GET
https://local.nexus.gateway/api/v1/quotes/{srcCtry}/{srcCcy}/{destCtry}/{destCcy}/
This will return the list of quotes for a specific currency pair. Nexus will automatically apply any improvements that each FXP provides to the requesting Source PSP, as well as any improvements that apply based on the value of the payment.
The GET /quotes/
API automatically applies any tier-based or PSP-based improvements, and checks the maximum value of a payment through both IPSs, adjusting the payment value automatically if necessary. Each steps is described in more detail below.
In Nexus a specific FXP can offer better rates for larger transactions. This works as follows:
For each specific Source Currency, an FXP can define a number of “tiers” at which better rates apply.
For each tier, the FXP will define how much the base rate (as provided in the POST /rates/
API) should be improved, in basis points.
FX Providers may also want to offer better rates to specific PSPs, for example, PSPs that are already customers of the FXP. In Nexus this works as follows:
An FXP can define the PSPs to which it wishes to offer improved rates
For each PSP, the FXP can define how much the base rate should be improved, in basis points.
When a Source PSP calls the GET /quotes/
API, Nexus will check whether any FXPs have registered improvements for that PSP and apply the improvement to the FXP's base rate.
An FXP does not need to set any PSP-based improvements. If no PSP-based improvement is set for a specific PSP, the base rate will apply.
Some instant payment systems set limits on the maximum size of a transaction which can be sent. An IPS may also set a lower limit on cross-border payments through Nexus than on domestic transactions.
If the PSP were to send a transaction that exceeded the maximum value of either the Source or Destination IPS, it will be rejected by that IPS. To avoid this, Nexus will validate that the Source Currency Amount and Destination Currency Amounts do not exceed the maximum value in each IPS before returning the list of quotes. This is done as follows:
For each rate in the quotes response, Nexus will calculate if either the Source Currency Amount or Destination Amount Currency Amount exceeds the relevant IPS’s MaxValue
If so, Nexus will calculate the maximum value (in both Source and Destination Currency Amounts) which can actually be sent
This information will be returned in the quotes list in “AdjustedSourceAmount
” and “AdjustedDestinationAmount
” fields
If the value of the payment is capped at a lower value than the Sender requested, the response for any adjusted rates will include the AdjustedReason
element, which will inform the PSP whether the Source IPS Max Value or Destination IPS Max Value (or both) was exceeded.
The Source PSP should also inform the Sender that the amount they requested was above the relevant limits and has been adjusted accordingly.
The Source Gateway returns a list of all quotes available for that currency pair, ordered from best to worst (ie. sorted by rate in descending order). Each quote includes the following information:
The Source PSP is responsible for selecting the FX Provider and quote that the PSP wishes to use. The PSP does not need to show the list of quotes to the Sender.
The PSP must store the Quote ID of the preferred quote in memory as the PSP will need to use it when setting up the payment instruction.
Part of the FX Service. Used by FXPs.
Nexus provides three APIs to FX Providers:
POST /rates/
- to issue new rates
POST /improvements/tiers/
- to register or update a tier-based improvement for a specific currency
POST /improvements/psps/
- to register or update an improvement for a specific PSP
In a production system, APIs would also be provided to allow to see FXP to “delete” or withdraw PSP-based and tier-based improvements. Rates could be withdrawn / expired by an FXP, but this is equivalent to the FXP exiting the market and should only be used in certain circumstances.
An FXP will submit a new rate using the Rates
API. Note: FXPs cannot update existing rates; instead they simply submit a new rate that takes effect immediately.
POST
https://local.nexus.gateway/api/v1/rates
When processing the rate update request, Nexus will:
validate the request (by checking that the FX Provider is set up to rate for that currency pair and has nominated validated Settlement Account Providers in both the Source and Destination Country)
save the new rate in the rates table
set any existing rates for this FXP-corridor combination to expire immediately
retrieve any tier-based improvements set by the FXP for this Source Currency
for each tier, calculate the improved rate
save a new rate in the rates table with the threshold defined in this tier and the new improved rate
The new rate is immediately shown to Source PSPs when they use the GET /rates/
API (alongside rates for that corridor from other FXPs).
POST /rates/
The Nexus Gateway will send a response message to the FX Provider to confirm that a rate has been successfully accepted and saved. The response message includes the newly created quote.
The response message also includes the current best available rate on the market (but not the identity of the FX Provider offering that rate). This allows each FX Provider to see whether the rates they offer are competitive, and to adjust those rates if necessary.
FXPs are NOT permitted to use the GET Rate API to see the full list of rates offered by their competitors; this will be enforced by both API permissions and the Nexus scheme rulebook.
FXPs can set tier-based improvements using the API:
POST
https://local.nexus.gateway/api/v1/tier_improvements
Allows an FXP to set a new tier improvement for a specific Source Currency
Each tier-based improvement must specify:
FXP Id – the FXP offering the improvement
UnitCcy – the Source Currency to which the improvement applies. (Tier-based improvements are always based on the Source Currency, not the Destination Currency)
Threshold – the smallest amount, in the Source Currency, at which the improvement rate applies. The Source Currency Amount of the payment must be greater than or equal to the threshold.
Improvement – a rate of improvement, recorded in basis points, which should be applied to the base rate.
For transaction values below the lowest threshold, the base rate provided by the FXP in POST /rates/
applies.
APIs to delete or “revoke” tier-based improvements have not yet been built and would need to be added to a production version.
FXPs can improvements for specific PSPs using the API below.
PSP-specific improvements are additional to any tier-based improvements. (Nexus calculates relevant tier-based improvements first, then applies any PSP-based improvements.)
A PSP-specific improvement needs to specify:
FXP Id – the FXP offering the improvement to a PSP
PSP Id – the PSP to which the improvement is being offered
Improvement – the improvement, in basis points, which should be applied to any rate offered by this PSP.
POST
http://local.nexus.gateway/api/v1/psp_improvements
Alllows an FX Provider to post a new improvement for a specific PSP. The improvement will apply to all quotes issued to that PSP, for all currencies that the FXP offers.
APIs to delete or “revoke” PSP-specific improvements have not yet been built.
Whenever Nexus successfully processes a payment (ie. receives a pacs.002 with a “ACCC” status code from the Destination IPS), it will send a notification to FX Provider whose rate was referenced. This notification should be used by the FXP to update its internal records of the balances of all its settlement accounts.
The FXP will provide the API endpoints or message queue to which these notifications should be sent during technical onboarding to Nexus.
This notification is structured as an ISO 20022 fxtr.017
message. The key elements of the fxtr.017 are described below:
A production version of Nexus would also include the ability for FXPs to generate aggregate reports on all transactions for which they provided FX in a certain time period. These reports would also include a breakdown of the calculation of the final rate, showing how the base rate, any tier improvements and any PSP improvements were applied to each quote. This functionality has not yet been built.
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|
Name | Type | Description |
---|
Tier-based improvements are offered to all PSPs and will be automatically applied by Nexus before the quotes are returned to the PSP. See for further detail.
Any PSP-specific improvements are set through a bilateral agreement with the PSP and FXP, outside of the Nexus scheme. See for further detail.
Name | Type | Description |
---|
Name | Type | Description |
---|
Name | Type | Description |
---|
countryCode*
String
ISO 3166 alpha-2 country code
STAGE & FAILURE REASON
EXAMPLE SCENARIO
ERROR MESSAGE RETURNED BY NEXUS
Proxy Conversion: Proxy is not linked to an account
The Sender assumes that they can send a payment using the Recipient’s phone number, but the Recipient hasn’t linked this number to a PSP account.
“No matching element was found”
Payment: Destination PSP not enabled to receive Nexus payments
The Destination PSP has not yet made the necessary changes to accept payments through Nexus, for example connecting their sanctions screening software.
“PSP of creditor account holder not reachable”
All Stages: Non-unique Message ID
The Source PSP sends the identical message with the equivalent content twice.
“Invalid message ID: XXX”
quote_id*
String
Id of the specific quote selected by the Source PSP
Country | Account Number | Bank/Branch Identifier Format |
Australia | Account number (9 digits) | BSB (Bank State Branch) code (6 letters) |
India | Account number (9-18 digits) | Indian Financial System Code (IFSC) (11 letters and numbers) |
Singapore | Account number (10 numbers) | Bank name (BIC for international payments) |
UK | Account number (8 digits) | Sort code (6 digits) |
USA | Account number (10-12 digit) | Routing number (9 digits) |
srcCtry* | String | Source Country, ISO 3166 alpha-2 |
srcCcy* | String | Source Currency, ISO 4217 alpha-3 |
destCtry* | String | Destination Country, ISO 3166 alpha-2 |
destCcy* | String | Destination Currency, ISO 4217 alpha-3 |
amt* | String | Value of the payment as defined by the sender (decimal) |
amtCcy* | String | Currency of the payment as defined by the Sender, ISO 4217 alpha-3 |
pspIdType* | String | Type of PSP Id: BIC, LEI or Other |
pspId* | String | Id of PSP |
limit | String | Number of quotes to retrieve (if not default) |
ELEMENT | USAGE |
Quote Id | To be referenced in the final payment instruction |
FXP Financial Institution Identifier | The financial institution identifier (BIC or LEI) of the FX Provider |
Rate | A specific FX Rate (where Source Amount * Rate = Destination Amount). This rate will include any tier-based or PSP-based improvements. |
Source IPS Id | The ID of the IPS where the FXP is able to receive funds |
Destination IPS Id | The ID of the IPS from which the FXP is able to pay out funds |
Adjusted Source Amount | If Sender specified the Destination Amount, this shows the value of (Destination Amount ÷ Rate) If the Sender specified the Source Amount, this will show the amount specified by the Sender unless the amount has been reduced by Nexus due to maximum values on either the Source or Destination IPS. |
Adjusted Destination Amount | If Sender specified the Source Amount, this shows the value of (Source Amount * Rate) If the Sender specified the Destination Amount, this will show the amount specified by the Sender unless the amount has been reduced by Nexus due to maximum values on either the Source or Destination IPS. |
unitCcy* | String | The Source Currency (ISO 4217 alpha-3) |
qtdCcy* | String | Destination Currency (ISO 4217 alpha-3) |
rate* | String | Decimal, 4 decimal places |
srcUPS | String | The Source UPS where the FXP holds an account (either directly or via a SAP) |
dstUPS | String | The Destination UPS where the FXP holds an account (either directly or via a SAP) |
unitCcy* | String | Source Currency to which this tier improvement applies |
threshold* | String | Minimum value at which a payment will qualify for this tier improvement (Payment must be equal or greater than the threshold) |
improvement | String | Improvement to add to the base rate in basis points |
fxpId* | String |
pspIdType | String | BIC, LEI or Other |
pspId | String | Id of the PSP |
improvement | String | Improvement in basis points to add to the base rate |
ISO 20022 fxtr.017 ELEMENT | MEANING |
OriginatorReference | ID of the underlying Nexus payment that made use of the FXP’s quote |
CommonReference | ID of the quote issued by Nexus to the PSP |
ProductType | “Nexus” |
TradingSideIdentification |
| BIC of the Source PSP |
CounterpartySideIdentification |
| BIC of the FXP |
TradeAmounts |
| Amount in target/destination currency that was transferred from the FXP’s account to the Destination PSP via the Destination IPS |
| Amount in source currency that the Source PSP paid to the FXP’s account via the Source IPS |
AgreedRate |
| Exchange rate applied (from the original quote, after any tier-improvements or PSP-based improvements have been added) |
| Source Currency |
| Destination/Target Currency |
TradingSideSettlementInstructions |
| BIC of the Destination Settlement Account provider and the account number of the FXP’s account at the SAP |
| BIC of the Destination PSP |
CounterpartySideSettlementInstructions |
| BIC of the Source PSP |
| BIC of the Source Settlement Account Provider and the account number of the FXP’s account at the SAP |
Where an IPS community (a) does not support ISO 20022, or (b) uses fields differently than defined in the Nexus standard messages, then the IPSO is responsible for translating messages:
before they are sent to Nexus
after they are received from Nexus
Nexus expects and will only accept the Nexus-standard ISO 20022 messages.
Some messages need to be transformed by Nexus after they are received from the Source IPS and before they are sent to the Destination IPS (or vice versa).
Transformation varies depending on the message type but may involve:
Moving the agents in an instruction (eg changing the Instructing and Instructed Agents after the first leg of the payment has been processed in the Source IPS)
Converting a currency and payment value from the Source Currency to the Destination Currency (according to the Nexus quote ID provided in the message)
For the proxy lookup message (camt.023), replacing the ID of the Assignee
The ISO 20022 pacs.008
used in Nexus contains all the information required to process a Nexus payment across two countries. By necessity, it contains more information than would be required for a domestic payment.
The Nexus pacs.008
will flow from the Source PSP to the Destination PSP, with minor transformation by Nexus in the middle.
An IPS may choose to translate the ISO 20022 (Nexus) messages to an alternative domestic message format. For example, some IPSs still operate using the older ISO 8583 standard. In this case, the IPS is responsible for:
Defining the translation map between the Nexus messages and the domestic messages
Translating messages to and from the Nexus standard
Ensuring that the translation to a domestic format does not lead to the loss or corruption of any of the essential data required for cross-border payments (particularly data required to support sanctions screening).
The key blocks of the Nexus pacs.008 message include:
Debtor – personal data about the Sender
Debtor agent – the details of the Source PSP
Creditor – personal data about the Recipient
Creditor Agent – the details of the Destination PSP
Interbank Settlement Amount – the Source Currency Amount (Nexus will calculate the Destination Amount based on the FX quote ID that the PSP provide below)
Intermediary Agent 1 (FXP‘s Settlement Account Provider, and the FXP’s account at the SAP, in Source country)
Intermediary Agent 2 (FXP’s Settlement Account Provider, and the FXP’s account at the SAP, in Destination Country)
Additional Remittance Information, which is where the FX Quote Id will be recorded (as there is no dedicated element for this information in the current pacs.008 specification)
Intermediary Agents can be retrieved using the Intermediary Agents API with the ID of the preferred quote.
Detailed usage guidelines for the pacs.008 will be shared here over the next few months.
An instant payment system (IPS) in Nexus is a payment system that:
Processes payments between accounts held at banks and/or regulated non-bank payment service providers (depending on the country)
Processes payments instantly or within seconds (usually a maximum of 30 seconds, although some systems may take up to 90 seconds)
Ultimately settles those payments in central bank money (either on a deferred net settlement basis, or through immediate settlement in central bank money of each individual transaction)
In the case of IPSs that make use of deferred net settlement, there must be a robust risk management regime (such as prefunding or collateral) that eliminates any settlement risk between PSPs during the settlement cycle.
Most IPSs only operate in a single currency – for example, SGD for Singapore’s FAST instant payment system, which processes payments in SGD. However, some IPSs operate in more than one currency, for example:
TIPS provides payments in euro (EUR) to PSPs in 19 eurozone countries, as well as payments in Swedish krona (SEK) to PSPs in Sweden.
In Hong Kong, the Faster Payments System provides payments in Hong Kong dollar (HKD) and Chinese renminbi (CNH), to the same community of PSPs.
To accommodate these scenarios, Nexus treats an IPS as a combination of an Instant Payment System (IPS) infrastructure and a specific currency.
Each IPS-plus-currency combination is treated in Nexus as a distinct Instant Payment System. IPSs that operate in two currencies are recorded in Nexus as two distinct IPS.
Each given an ID that includes the 3-letter currency code and a 4-letter description of the payment system, eg:
SGDFAST – Singapore’s FAST, processing payments in SGD
EURTIPS – ECB’s Target Instant Payments Service, processing payments in EUR
SEKTIPS – ECB’s TIPS but providing payments in SEK
HKDHKFP – Hong Kong’s Faster Payments System processing payments in HKD
CNHHKFP – HK’s FPS processing payments in CNH
MYRRPPX – Malaysia’s real-time payments platform, processing payments in MYR
Nexus uses a standard pacs.002
payment status message. Nexus will perform some minor transformation (changing the instructing and instructed agents) when forwarding the message from the Destination PSP to the Source PSP.
The status codes use a subset of the ExternalPaymentTransactionStatus1Code
from the ISO20022.org external code sets. Status codes used in the Nexus pacs.002
are as follows:
Detailed usage guidelines for the pacs.008 will be shared here over the next few months.
TERM | DEFINITION |
---|
ACRONYM | MEANING |
---|
PACS.002 TRANSACTION STATUS CODE
CODE MEANING
REASONS FOR USE
ACTION
ACCC
Accepted Settlement Completed Creditor Account
Destination PSP is happy to accept the payment. (Payment did not trigger alert against sanctions lists, OR a previous alert has been identified to be a false positive)
Destination PSP should immediately credit the recipient’s account
ACWP
Accepted Without Posting
Payment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account.
Destination PSP holds funds and tries to resolve sanctions alert within the time permitted in the Nexus rulebook.
RJCT
Rejected
The Destination PSP is unable or willing to accept the payment. (Possible reasons: account closed or does not exist; D-PSP considers payment to be suspicious; the D-PSP previously replied with ACWP but cannot resolve the sanctions alert within the permitted Nexus SLA)
No further action, unless it follows an earlier pacs.002 with status ACWP.
If RJCT follows an earlier ACWP, the
Destination PSP should THEN send pacs.004
payment recall request to return the funds
BLCK
Blocked
A payment transaction previously reported with status 'ACWP' is blocked, for example, funds will neither be posted to the Creditor's account, nor be returned to the Debtor. Used when the Destination PSP believes that the payment is illicit and should be reported to authorities.
Freeze the funds. File a suspicious activity report to the authorities.
ACTC
AcceptedTechnicalValidation
Used by a PSP when acting as Settlement Account Provider for a specific payment.
Adherence Agreement | Agreement between Scheme and Participant of the Scheme. NB: Different versions of adherence may exist, according to the specific chosen role(s) of the Participant. |
Base Rate | The base rate for a currency pair which is provided by the FX Provider via POST /quotes/, for transactions starting from value of 0.01. Final rates provided to the PSP may be improved depending on any tier-based or PSP-based improvements set by the FX Provider |
Business Identifier Code (BIC) | An 8 or 11 character ISO code assigned by SWIFT and used to identify a financial institution in financial transactions (ISO 9362). |
Destination | In the Nexus terminology, Destination refers to the receiving side of the Nexus Payment, i.e. the PSP, the IPS, the SAP and the Gateway involved, to move the funds transmitted by the Payer, into the Payee’s account. |
Destination Currency | The currency of the Recipient. Also known as “Quoted Currency” in ISO 20022 terminology. |
Destination Gateway | The Nexus Gateway deployed by the Destination IPS in a specific Nexus Payment. |
Destination IPS | The IPS that receives a Nexus Payment for delivery to the Destination PSP, where the Payee of the Nexus Payment holds a Payment Account. |
Destination Settlement Account Provider (D-SAP) | For a specific Nexus payment, this is the SAP in the Destination Country. Funds are paid from the Destination SAP to the Destination PSP. |
Final Rate | The exchange rate of an FX Provider as provided by Nexus to a Source PSP. This includes any improvements that have been applied based on the size of the transaction or the PSP requesting the rates. |
FX Provider | A party that provides FX conversion rates and executes cross currency conversion using liquidity providers in source and destination countries. The FX Provider may be a member of an IPS or may access the IPS indirectly via Settlement Account Providers. |
Improvement | A value in basis points, provided by the FXP, defining how much the base rate provided by the FXP should be improved for larger payments or for specific PSPs. |
Instant Payment | A payment executed end-to-end, where the funds being transferred from the account of a Payer are irrevocably made available in the account of the Payee within seconds (typically less than 20 seconds). |
Instant Payment System (IPS) | A payments system executing instant payments according to the rules of a local or local Payment Scheme or payments protocol |
Instant Payment System Operator (IPSO) | IPS Operator: the operator of an instant payment system. The legal entity which contractually provides clearing and settlement services to its participants. Also the entity which adheres to Nexus as participant (in the IPSO role). |
Legal Entity Identifier (LEI) | The Legal Entity Identifier, defined as ISO Standard 17442 |
Member | A participant of an IPS. The member can be a direct or indirect participant. A direct participant is a member, which has its own settlement account in the settlement system (for example, the RTGS of the central bank for IPS that settle in central bank money). An indirect participant is a member not having its own settlement account in the settlement system. An Indirect Participant has a contractual relation with a Direct Participant, to allow its payments being service on the settlement account of the Direct Participant. NB: In the context of this Rulebook, the term “member” is used in a limited sense, specifically to refer to the participation in the local IPS (and may cover one or more local schemes – not only Instant Payments, but also batch payment, direct debit or other). The term “Nexus Scheme Participant” is used in this Rulebook to refer to an entity that participates in the Nexus Scheme. (A PSP may be a member of a local IPS, but not a Participant in the Nexus Scheme.) Where in this Rulebook reference to participation in Nexus Scheme is meant, the term “Nexus Scheme Participant” is used. |
Nexus Gateway (NGW) | A software application deployed as an extension of an IPS, through which Nexus Payments are routed and processed. (see also Source Gateway and Destination Gateway). |
Nexus Payment | A near-instant, cross-border payment that complies with the rules and standards of the Nexus Scheme. Most (but not all) Nexus payments are also cross-currency i.e. the Sender’s currency is different from the Recipient’s currency. |
Nexus Scheme | The legal rules (based on the law of [jurisdiction to be decided]) and technical standards, together comprising the Nexus cross-border scheme. |
Nexus Scheme Organisation (NSO) | The non-profit organisation established in a jurisdiction to be decided, which is accountable for the scheme management. The contracting party for the Adherence Agreement signed by Scheme Participants. The term ‘Scheme Organization’ refers to the organization performing the role of the Scheme Owner. See also Nexus Scheme Owner. |
Nexus Scheme Owner | The legal entity that is performing the role of owning, and maintaining, the Nexus Scheme. It is envisaged that this role for Nexus will be performed by the Scheme Organisation . For clarity: A Scheme Owner does not need to be a Financial Institution, nor does it need to be a Payment System Operator. |
Nexus Scheme Participant | A legal entity having signed an Adherence Agreement with the Nexus Scheme Owner Nexus Scheme Participants can be: a) PSP (bank or non-bank), acting in the role of PSP and/or Settlement Account Provider; b) IPSO; or c) FX Provider. |
Participant | A legal entity having signed an Adherence Agreement with the Nexus Scheme Organisation |
Payee | The account holder whose account is credited for the payment. Payee = Recipient = Creditor (in ISO 20022 terminology) |
Payer | The account holder whose account is debited for the payment. Payer = Sender = Debtor (in ISO 20022 terminology) |
Payment Scheme | Definition BIS (proposed): A set of business rules, data elements and technical standards to which Participants of the Scheme must comply. |
Payment Service Providers (PSP) | PSPs include all entities that are eligible to send and receive domestic instant payments through a particular IPS. These could be banks or non-bank financial institutions according to local eligibility criteria. Every member of an IPS will be listed as a PSP in Nexus, whether or not they are participating in Nexus. Each PSP record will contain an indication of whether the PSP is participating in Nexus and therefore is reachable for Nexus payments. |
Payment System | (definition from BIS) A set of instruments, procedures, and rules for the transfer of funds between or among participants; the system includes the participants and the entity operating the arrangement. |
PSP-based Improvements | An FXP may want to offer a specific PSP (eg a regular customer) a better rate than the base rate(s). They can do so by defining an improvement that applies only to that PSP. |
Quoted Currency | ISO 20022 terminology for Destination Currency (the Recipient’s currency) |
Rate | Exchange rate, where Source Currency Amount * Rate = Destination Currency Amount |
Recipient | The individual or business to whom funds are being paid. Equivalent to payee, beneficiary, or Creditor (in ISO 20022 terminology). |
Rulebook | The Nexus Scheme Rulebook |
Scheme | See Payment Scheme. |
Sender | The individual or business initiating the payment to the Recipient. Equivalent to payer, originating customer or Debtor (in ISO 20022 terminology). |
Settlement Account Provider (SAP) | A PSP that is a member of an IPS and which provides an account in which an FX Provider can hold funds. For a specific Nexus payment, funds are paid out of this account to the Destination PSP |
Source | In the Nexus terminology, Source refers to the initiating side of the Nexus Payment, I.e. the PSP, the IPS, the SAP and the Gateway involved to move the funds to be transmitted to the Payee out of the Payer’s account. |
Source Currency | The currency of the Sender. Also known as “Unit Currency” in ISO 20022 terminology |
Source Gateway (SGW) | The Nexus Gateway deployed by the Source IPS in a Nexus Payment. |
Source IPS | The IPS that sends a Nexus Payment to a Source Gateway. The Nexus Payment is instructed by a Source PSP , to a Source IPS, on behalf of the Payer, who holds a Payment Account at the Source PSP. |
Source Settlement Account Provider | The Source Settlement Account Provider is a member of the Source IPS. The Source PSP sends funds (in the Source Currency) to the FX Provider’s account at the Source Settlement Account Provider. This payment is processed through the Source IPS. |
Tier-based Improvements | FXPs typically offer better exchange rates for larger transactions (so the Recipient receives a larger Destination Currency Amount for a given Source Currency Amount). In Nexus, an FXP can set tiers at which better rates apply. Each tier is defined by a starting threshold value and an improvement that applies to payments above that threshold. |
Unit Currency | ISO 20022 terminology for Source Currency (the Sender’s currency) |
AML | Anti-Money Laundering |
API | Application Programming Interface |
BCS | Banking Computer Services Pte. Ltd. |
BIC | Business Identifier Code |
BIS | Bank for International Settlements |
BISIH | Bank for International Settlements Innovation Hub |
CFT | Countering the Financing of Terrorism |
CNH | Chinese Yuan (when traded offshore) |
CPMI | Committee on Payments and Market Infrastructures |
DNS | Deferred Net Settlement |
ECB | European Central Bank |
EUR | Euro |
FAST | Singapore’s instant payment system: Fast and Secure Transfers |
FSB | Financial Stability Board |
FX | Foreign exchange |
FXP | Foreign exchange provider |
GDP | Gross Domestic Product |
HKD | Hong Kong Dollar |
IBAN | International Bank Account Number |
IOSCO | International Organisation of Securities Commissions |
IPS | Instant Payment System |
ISO | International Standards Organisation |
JAXB | Java XML Binding |
JMS | Jakarta Messaging API (for Java) |
MPL | The TIPS Mobile Proxy Lookup service |
NSO | Nexus Scheme Organisation |
PSP | Payment Service Provider (used inclusively to refer to banks and non-bank PSPs) |
RDS | Nexus Reference Data Service |
RFI | Request for Information |
RPP | Malaysia’s Real-time Retail Payments Platform |
RTGS | Real Time Gross Settlement |
SAP | Settlement Account Provider |
SEK | Swedish Krona |
SGD | Singapore Dollar |
TARGET | Trans-European Automated Real-time Gross settlement Express Transfer system |
TIPS | TARGET Instant Payment Settlement |
UPI | India’s Unified Payments Interface |
USD | United States Dollar |
UX | User experience |
Editorial revision of content on FX Providers to clarify and reduce duplication.
Removal of the concept of Unique Payment System. Where an IPS operates in two currencies, it will be recorded in Nexus as two separate IPS (eg for Hong Kong, "HKDHKFP" and "CNHHKFP").
Updated GET /countries/ API documentation to JSON API. (Other APIs will be converted to JSON in due course.)
Updated the response from GET /upss/
(unique payment systems) to remove information about (a) whether IBANs are accepted, (b) the format of a local PSP identifier (such as BIC) and (c) the format of a local account identifier. All this information will be provided on a per-country basis by the revised Addressing & Proxy Resolution service (forthcoming).
Updated entire technical documentation with results of the Nexus Phase 2 proof of concept.
Nexus is led by the BIS Innovation Hub's Singapore Centre. Please contact the team at singapore.centre@bisih.org.
[Test of minor change request]
Nexus also defines market practice guidelines for the following ISO 20022 messages, which will be added here in due course:
pacs.004
pacs.028
acmt.023
acmt.024
camt.026
camt.028
camt.029
Most countries have a single IPS, operating in a single currency. However in Europe and the United States (in particular) there may be multiple IPSs in a single country. (For example, a PSP in Spain may be reachable through TIPS, RT1 or IberPay.)
As soon as two or more IPSs in the same country connect to Nexus, the following complications could arise.
This complication would arise where:
There is more than one IPS in the Source Country
The Source PSP is a member of one of the IPSs (IPS-A), but not the other (IPS-B)
Some FXPs hold settlement accounts in one IPS (IPS-B) but not the other (IPS-A)
These quotes are not available to the Source PSP, because they cannot make a payment to the FXP’s account in IPS-B
Recommended approach:
The PSP needs to check that it only selects a quote where the Source IPS Id (provided in each quote) is for a IPS that the PSP is a member of (eg IPS-A in the example above).
This complication can be addressed in Nexus. Nexus is aware of which IPS each PSP has access to, so the FX Service can be adapted to only return quotes that the Source PSP can actually use. This feature would only be required once two IPSs in the same country join Nexus, and so it was not developed in the proof-of-concept.
This scenario arises when:
There is more than one IPS in the Destination Country (eg IPS-C and IPS-D)
Some FXPs are members of one IPS (IPS-C) but not the other (IPS-D)
The Destination PSP is a member of one IPS (IPS-D) but not the other (IPS-C)
The Source PSP therefore needs to select a quote from an FXP that is a member of IPS-D
The challenge is that:
In the recommended user experience, the Source PSP should show the Sender the exchange rate before the Sender is asked to provide addressing details for the Recipient
However, the Source PSP will only know the Destination PSP after addressing details have been provided by the Sender
Therefore the preferred quote may no longer be applicable (for example, if the preferred quote selected above is for an FXP that is a member of IPS-D but not IPS-C).
Recommended approach
If the IPSs element contains only one IPS, the PSP can display the preferred exchange rate to the Sender with the message that this rate is secured for at least 10 minutes (or words to that effect).
However, if the IPSs element contains more than one IPS, the PSP should instead display the message that “This rate is provisional and will be confirmed once the Recipient’s PSP is known” (or words to that effect).
After the Source PSP calls the GET /creditors/
API operation, they should review the /CdtrInfRspns/PSP/RchblIPSs
element for the IPS Ids of the IPS(s) in which the Destination PSP is reachable.
If the preferred quote’s DestinationIPSId
is not found in the /CdtrInfRspns/PSP/RchblIPSs
element, the Source PSP will need to select another quote. (It is advisable to call the GET /quotes/
API operation again to get the latest rates.)
The PSP can now show the Sender the new quote, this time as “Guaranteed for 10 minutes”.
© Bank for International Settlements ("BIS")
Use of this website (nexus.bisih.org) constitutes agreement by users of this website ("Users") with the following terms and conditions.
All copyright and other intellectual property rights in the publications available on this website, including processes, message flows and API specifications contained in the publications ("Nexus Material") are owned by the BIS. Except as outlined below, all rights are reserved.
Users may use Nexus Material on the following conditions without obtaining written permission from the BIS (for any other use, BIS permission must be requested by email to singapore.centre@bisih.org)
Subject to clause 2(2) below, Users may use Nexus Material to develop payments software, products or services. Nexus Material may not be sold.
Users may use or reproduce a limited extract of Nexus Material in other publications or products free of charge, provided the BIS is cited as the source and, with respect to translations, a statement is included that the translation is not an official BIS translation. By way of guidance, a "limited extract" means any extract of not more than 400 words of text or two tables or graphs and the underlying data made available by the BIS, and in any case not exceeding 10% of the relevant publication.
Users who maintain an external website may include electronic links to this website (nexus.bisih.org), as long as this:
does not infringe the intellectual property rights of the BIS, in particular with respect to its names, acronyms and logos; and
is not misleading, for instance by implying endorsement by or affiliation with the BIS.
The BIS is an international organisation which fosters cooperation among central banks and other agencies in pursuit of financial and monetary stability. It has no supervisory or regulatory functions or responsibilities. Its banking services are provided exclusively to central banks, monetary authorities and international financial institutions. The BIS does not accept deposits from, or provide banking services or advice to, private individuals or companies. The BIS has set up an Innovation Hub (the “BISIH”) to foster innovation and greater collaboration amongst the central banking community globally, enhance the understanding of financial technology and contribute to the development of innovative solutions to benefit and enhance the financial system.
The Nexus Material is provided “as is”. The BIS does not warrant or guarantee the accuracy, completeness or fitness for purpose of any information or material on this website. Under no circumstances shall the BIS be liable for any loss, damage, liability or expense suffered in connection with reliance by any person on any such information or material.
Nothing on this website shall be construed as containing any investment recommendation or advice.
Except where expressly stated to the contrary, the views stated in any material on this website are those of the authors thereof and are not necessarily those of the BIS or its member central banks.
The designations used and the presentation of material on this website do not imply the expression of any opinion whatsoever on the part of the BIS concerning the legal status of any country, area or territory or of its authorities, or concerning the delimitation of its frontiers or boundaries.
This website may contain electronic links to other websites. This does not imply any endorsement or responsibility on the part of the BIS with respect to the opinions, ideas, data or products presented on other websites.
Under no circumstances shall the BIS be liable for any loss, damage, liability or expense suffered in connection with the use of this website, including (but not limited to) any fault, error, omission, interruption or delay.
The BIS may collect information about Users' browsing history as well as certain other information related to Users' use of and visits to this website through the use of various technological tools - including, but not limited to, cookies, tags, beacons and Internet Protocol (IP) addresses. This website uses Google Analytics to see how many visitors have come to the website, from where and for how long. Please note that this website does not use the advertising or marketing features of Google Analytics.
The BIS may at any time without notice:
add to, update or modify material on this website; or
limit access to or discontinue the whole or any part of this website.
Nothing in these terms and conditions shall constitute a waiver of any of the privileges or immunities of the BIS in any jurisdiction.
These terms and conditions are governed by the laws of Switzerland.
In some cases, a Source PSP may be able to act as its own FX Provider. This is possible where the Source PSP holds an account with a Destination Settlement Account Provider, so that it can initiate the second payment (to the Destination PSP) from its own account at the Destination Settlement Account Provider. In this case, the Source PSP may want to define its own FX rate. It can do this by:
Posting an FX rate to Nexus (which will also be visible to other Source PSPs requesting that rate)
Setting a PSP-specific improvement for themselves, which will be applied by Nexus whenever they select themselves as the FX Provider.
The Source PSP can now call the GET /quotes/
API operation as normal and select itself as the FX Provider.
Example
PSP-E is based in Singapore but holds funds in an account with a Nexus-participant Settlement Account Provider in Malaysia.
They onboard with Nexus as an FXP (FXP-E).
As FXP-E, they register a PSP-specific discount of 200 basis points for PSP-E.
As PSP-E, they request a quote from Nexus. Nexus automatically applies the improvement to FXP-E’s quote. PSP-E sees themselves listed in the list of quotes, with a quote that is more competitive than the rest of the market (because of the discount they give to themselves). They select this quote.
In many cross-border payments between smaller currencies, the Source Currency is first converted into a third currency – often the US dollar – which is then converted into the Destination Currency.
Nexus does not currently provide this “third currency” mechanism; the FX Provider must swap the Source Currency directly for the Destination Currency. This may mean that certain, less common currency pairs suffer from having only one FX Provider (or even none).
Providing a third-currency route for Nexus payments is possible and would be necessary as the network scales, in order to connect a larger number of countries. However, it does add significant complexity. It would require payments to be made in three IPSs, may require more than one FX Provider and may extend payment times.
This will be addressed in a future phase of work.
An IPSO must sign an adherence agreement to become a direct member of the Nexus Scheme. The adherence agreement requires them to comply with the various obligations and responsibilities of being an IPSO in Nexus, as defined in the Nexus Scheme rulebook.
Eligibility requirements for Nexus will be defined in detail in the Nexus Scheme Rulebook, but at a high level:
An IPSO must be able to process individual payments between accounts in seconds.
An IPSO may use a Deferred Net Settlement model or real time gross settlement in central bank money.
Where the IPSO uses a Deferred Net Settlement approach:
net settlement must take place in central bank money
a pre-funding, collateral or other adequate risk management regime must be in place to ensure that there is no unsecured credit risk between PSPs during the settlement cycle.
The IPSO must meet the other obligations and requirements defined in the Nexus Scheme Rulebook.
Once an IPSO has signed the adherence agreement with the Nexus Scheme Organisation, it can start the technical process of integrating with Nexus and undertake technical testing.