The example user journey below demonstrates how an individual Sender would use their existing PSP channel (eg an app) to make a payment through Nexus, and describes the steps taken by Nexus behind the scenes.

Step 1: Ask the Sender to select the country and currency

1. Using data retrieved from the GET /countries/ API operation, the Source PSP (Sender's PSP) can display a dropdown Countries list to the Sender via the Source PSP’s app or other channel. (Left and middle figure below.)

2. 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:

   1. Display a second form element (eg <select> or <radio>) that lists the currencies available (Right hand screen below.)

   2. Ask the Sender to select the currency that the Recipient expects to receive

3. The app should store the selected country (and currency, if applicable) in memory, as it will be required when retrieving FX quotes

Step 2: Ask the Sender to define EITHER the amount that should be sent, OR the amount that should be received

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 DebtorAccountAmount which will be debited from the Sender/Debtor's account), OR

• The amount the Sender wishes the Recipient to receive (the CreditorAccountAmount which will be credited to the Recipient/Creditor's account)

Validating maximum transaction amounts in-app

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 inform the Source PSP if the requested amount exceeds the Source Currency Amount or Destination Currency Amount at a given exchange rate. 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 input:

• The Source Currency Amount field (labelled “You send” in the example screen) can be capped to either:

  • 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 /countries/{countryCode}/currencies/{currencyCode}/max-amounts with the country code of the PSP’s home country.), OR

  • the maximum value that the PSP is willing to send (if lower than the local IPS limit)

• The Destination Currency Amount field (labelled “They receive” in the example screen) should be capped to the maximum defined in the response to GET /countries for the selected Destination Country.

As shown in Step 2, the Sender can choose to set EITHER:

• the amount to send in their own Source Currency. This is the DebtorAccountAmount which will be debited from the Sender/Debtor's account, defined in the Source Currency, OR

• the amount the Recipient should receive, in the Recipient's own Destination Currency. This is the CreditorAccountAmount which will be credited to the Recipient/Creditor's account, defined in the Destination Currency

The quote request process is slightly different depending on which option the Sender chose.

Step 3: Source PSP prepares quote request to Nexus

1. The Source PSP should use the GET /quotes API operation to retrieve quotes. This API accepts the following values:

   1. Source Country

   2. Source Currency

   3. Destination Country

   4. Destination Currency

   5. Amount

   6. Amount Currency (ie the 3-letter code for the Source Currency or Destination Currency)

2. If the Sender defined the DebtorAccountAmount (ie amount to send), then the Source PSP should set the following values in the quote request:

   1. Amount Currency = Source Currency

   2. Amount = DebtorAccountAmount minus Source PSP Deducted Fee

1. Alternatively, if the Sender defined the CreditorAccountAmount (ie amount the recipient should receive), then the Source PSP should set the following values in the quote request:

   1. Amount Currency = Destination Currency

   2. Amount = CreditorAccountAmount

1. The Source PSP sends a quote request to the GET /quotes API (see APIs).

Step 4: Nexus generates quotes

1. Nexus will retrieve the basic rates for the currency and country pair selected, from those FXPs that have confirmed they are happy to provide FX to this Source PSP

2. For each rate, Nexus will:

   1. automatically apply any improvements offered by that FXP based on size of the transaction or the PSP requesting the rate. (See Improving rates for larger transactions and Improving rates for specific PSPs for more detail.)

   2. If the Sender defined the DebtorAccountAmount, the Source PSP will have subtracted their own Destination PSP Deducted Fee and then requested a quote for the net amount - the Interbank Settlement Amount in the Source Currency. Nexus will multiply this amount by the (possibly improved) exchange rate to get the amount that will be transferred from the Destination SAP to the Destination PSP (the Interbank Settlement Amount in Destination Currency).

      1. Nexus will also calculate the Destination PSP Deducted Fee and include this in the quote response.

      2. Nexus will calculate the amount that will be credited to the Recipient's account after the Destination PSP (Deducted) Fee has been deducted. This is included the quote response as CreditorAccountAmount.

   3. Alternatively, if the Sender defined the CreditorAccountAmount, Nexus will:

      1. work backwards from this amount to calculate the Destination PSP (Deducted) Fee.

      2. add the CreditorAccountAmount and Destination PSP (Deducted) Fee together, and divide the result by the (possibly improved) exchange rate to identify how much the Source PSP needs to transfer to the FXP. This amount will be included in the Quote response as Interbank Settlement Amount (in the Source Currency).

   4. Nexus will check that the Interbank Settlement Amount (in the Source Currency) and CreditorAccountAmount (at the given rate) do not exceed the MaxAmount values in either the Source or Destination IPS

      1. 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, and include a flag cappedToMaxAmount = true in the quote response, which shows that the amount exceeded the cap. If this value is true, the Interbank Settlement Amount shown is the maximum that can successfully be sent through both IPSs at the current exchange rate.

3. 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 of the chosen quote must be referenced when the PSP submits the pacs.008 payment instruction in #toc116457927)

Step 5: Source PSP selects the preferred quote

1. The Source 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.

2. The PSP does not show the list of quotes to the Sender.

Step 6: Source PSP displays the exchange rate and amounts to the Sender

Now the exchange rate and Source Currency Amount and Destination Currency Amount can be shown to the Sender:

• If the Sender defined the DebtorAccountAmount (ie the amount they wish to send, in their own currency), the amount fields should be updated as follows:

  • DebtorAccountAmount = the DebtorAccountAmount originally defined by the Sender (ie no change)

  • CreditorAccountAmount = the CreditorAccountAmount which was calculated by Nexus and provided in the Quote response;

• If the Sender defines the CreditorAccountAmount (ie the amount that the Sender wishes the Recipient to receive),

  • DebtorAccountAmount = the Interbank Settlement Amount (in Source Currency) provided in the quote response plus the Source PSP (Deducted) Fee

  • CreditorAccountAmount = the CreditorAccountAmount which was originally defined by the Sender. (This will be the same as the CreditorAccountAmount included the quote response.)

• The effective exchange rate applied should also be shown to the Sender

We recommend starting by reading chapter 2 of the 2024 overview 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 begins with a 60-second summary.

• Payment Setup describes the scope of Nexus payments and how they are setup from the Sender's perspective. It describes some of the information that is exchanged between the Sender's bank (the Source PSP) and Nexus.

• Addressing & Proxy Resolution describes how payments in Nexus can be addressed using proxies (like a mobile number), International Bank Account Numbers or local account numbers. It also describes the features that allow the Sender to confirm the identity of the payee.

• FX Provision describes the role of financial institutions who swap the sender's currency for the recipient's.

• Payment Processing describes how banks or payment service providers (PSPs) and instant payment system operators (IPSO) should process Nexus payments, and what to do when something goes wrong.

• Settlement Access Provision describes the role of the financial institutions who provide accounts to FX Providers (and some foreign PSPs) so that they can provide FX to Nexus payments, despite not being a full member of a country's IPS.

• Messaging & Translation describes the specific ISO 20022 messages that are used in Nexus. It also describes how countries who do not use ISO 20022 domestically should translate to and from the Nexus standard messages.

Enabling instant cross-border payments

Nexus is a BIS Innovation Hub project. This site contains detailed technical and functional information about Nexus, and is written for the payment system operators, banks, payment service providers and FX Providers who may be participating in Nexus.

• If you are new to Nexus, we recommend starting with chapter 2 the latest (2024) Nexus report for an overview of the scheme & governance, business model and technology architecture of Nexus.

• The Nexus project page includes the latest updates to the project

This site contains detailed technical documentation, covering:

• implementation guides for each type of participant in Nexus

• ISO 20022 message specifications for Nexus

• API specifications

More than 70 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 an instant payments system to reach all other countries in the network. Nexus could significantly accelerate the growth of instant cross-border payments

The Nexus blueprint has been developed over 3 years with significant input from instant payment system operators, central banks, commercial banks and payment service providers and FX providers who have a significant presence in FX markets and cross-border payments. We welcome further feedback and suggestions to enhance the blueprint.

Next steps for Nexus

In the next phase of work, BIS IH Singapore Centre is collaborating with the central banks of India, Malaysia, the Philippines, Singapore and Thailand as they prepare to connect their domestic payment systems. Please refer to the Nexus project page for the latest news on implementation of Nexus.

(Use of this website and the Nexus materials is subject to the terms and conditions.)

Nexus supports account-to-account payments between individuals (known as person-to-person (P2P) and consumer-to-consumer (C2C)) and businesses (B2B), or between individuals and businesses (P2B, B2P). These payments are initiated by the sender entering a proxy, such as a mobile number, or account details into the app of the Sender's PSP.

Nexus currently supports Single Instant Cross-Border Cross-Currency Payments:

“Single payment”

Nexus supports single payments only. A pacs.008 payment instruction message sent to Nexus must only contain a single transaction. Nexus will process each payment individually and PSPs will accept/reject each Nexus payment individually.

“Instant”

Nexus processes instant payments. A domestic instant payment is defined as a payment executed end-to-end, where the funds being transferred from the account of a Sender are made available in the account of the Recipient, irrevocably, within seconds (typically within 20 seconds).

Nexus has the ability to support both time-critical and non-time-critical account-to-account payments:

• Time-critical payments include urgent payments and point-of-sale payments (eg where the Sender is standing at the till or sat in a taxi, waiting for a payment to complete before they can leave).

• Non-time critical payments are those payments where it is acceptable for the payment to be slightly delayed in the case that the alerts generated by compliance checks and sanctions screening cannot be resolved instantly.

Whether a payment is time-critical or non-time critical is defined in the payment message.

“Cross-Border, Cross-Currency” Nexus is designed for instant payments requiring a currency conversion, using an FX Provider. See .

The sanctions screening requirement

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”).

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 and account number as a minimum. Adding further information in addition to the name will reduce the likelihood of the payment triggering a false positive alert and being delayed.

Step 10: Review the data available for sanctions screening; ask the Sender for Recipient data if necessary

The PSP should now review the acmt.024 response to confirm whether:

• Name is present

• Account number 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 Source PSP can display fields for them to enter the Recipient’s address. The Source PSP should check the information it received from GET /countries/{countryCode}/ to establish if these additional fields are mandatory in the Destination IPS.

Although the Source 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 acmt.023 account resolution request, the information is shared securely through Nexus and not shown to the Sender, except for the display name).

Step 11: Screen the payment against applicable sanctions lists

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 Source PSP has already screened the Sender as part of the PSP’s regular KYC, AML and screening processes.)

If the Destination PSP supports the acmt.023/acmt.024 account resolution process, Nexus will already have issued a acmt.023 request to the Destination PSP during the proxy and account resolution process.

Nexus-specific terminology

ISO 20022 Terminology

This guide uses the following ISO 20022 terminology:

• Debtor is the sender of the payment. In this document, the Debtor is referred to as Sender.

• Debtor Agent is the PSP or bank that holds an account for the Debtor. In this document, the Debtor Agent is referred to as the Source PSP.

• Creditor is the intended recipient of the payment. In this document, the Creditor is referred to as Recipient.

• Creditor Agent is the PSP or bank that holds an account for the Recipient. The Creditor Agent is referred to in this document as the Destination PSP.

• Proxy (also known as alias) is a piece of information, such as a mobile phone number, that can be associated with an account.

  • We use the term Proxy Directory to refer to the database of proxies (aliases) and the accounts they are associated to, and Proxy Directory Operator (PDO) to refer to the operator of the Proxy Directory service (who may also be the same entity as the Instant Payment System Operator). No equivalent terminology exists in ISO 20022.

• Element is a data field in an ISO 20022 XML message.

Other terms used

• Corridor – the payment route between two currencies in two different countries

• Currency pair – the source currency and destination currency (in a particular direction). Often written as XXXYYY, for example SGDEUR relates to a payment where the Source Currency is Singapore dollars and the Destination Currency is euro.

• Base Rate – the basic, unimproved rate provided by the FXP to Nexus for a specific currency pair

• Final Rate – the rate provided by Nexus to a PSP once any relevant tier-based or PSP-based improvements have been applied to the base rate. It is the ratio between the amount the Source PSP pays to the FXP and the amount the FXP pays to the Destination PSP.

Step 12: Ask Sender to review and confirm details

The Source 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 Source 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 exchange rate that will be applied. This is the effective exchange rate paid by the Sender - the ratio between the amount deducted from the Sender's account, and the amount that is ultimately credited to the Recipient's account (rather than the exchange rate paid by the Source PSP to the FXP). See

• The fees that the Sender will be charged by the Source PSP.

See for further details.

Sender's payment reference

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 pacs.008 element /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/RmtInf/Strd/CdtrRefInf/Ref . (The message field can alternatively be added at any other point in the flow.)

7.1 App generates the addressing form

Next the Source 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 available proxy types, since these are usually easier for the Sender to input, followed by IBAN (if accepted), followed by any domestic account formats.

This form can be generated dynamically using the response to the GET /countries/{countryCode}/address-types-and-inputs. 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.

7.2 Sender selects an address type

The Source PSP should present the Sender the list of available address types, as shown below. The Sender can select the appropriate address type based on what information the Recipient has given them.

7.3 Sender enters addressing details

Each addressType is made up of one or more corresponding inputs. For example, an IBAN only requires one input (the IBAN text itself) whereas a proxy will require both the proxy ID value itself (eg a mobile phone number) and the proxy type code (eg MNBO).

On the next screen, the Sender should be asked to enter the specific addressing details, depending on the option they selected before.

Step 8: PSP sends proxy or account details to Nexus

1. 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 financial institution identifier (eg BIC) and account number, or return an error if the proxy is not registered to an account.)

3. Nexus will respond to the Source PSP with:

   1. the financial institution identifier

   2. the account number

   3. the Recipient’s full name, visible only to the Source PSP

   4. the Recipient's display name, which can be shown to the Sender

   5. any further personal data that is provided by the Proxy Directory or Destination PSP

Step 9: Ask Sender to Confirm Payee

The Source PSP should now ask the Sender to confirm that they recognize the Recipient’s name before proceeding with the payment. This "confirmation of payee" or "verification 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 acmt.023 proxy or account resolution request will include the Recipient’s real name or a partially masked display name. This information is retrieved from either the proxy directory or the Destination PSP.

The Source PSP should show this to the Sender and ask them to confirm that this is the name they are expecting to see.

Now that the Sender has approved the payment, the PSP must set up the Nexus-standard pacs.008 payment instruction (or domestic equivalent) and submit it to the local IPS.

Step 13: Retrieve the Intermediary Agents (FXP’s accounts)

1. The PSP uses the API operation GET /quotes/{quoteId}/intermediary-agents to retrieve the Intermediary Agents, based on the FX Quote 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 the FXP's account in the Destination Country.

Step 14: Construct the Nexus pacs.008 payment instruction

1. The PSP constructs the pacs.008 payment instruction: this will make use of information from the earlier responses to:

   1. GET /quotes

   2. The acmt.023 proxy or account resolution request

   3. GET /quotes/{quoteId}/intermediary-agents

2. The Source PSP should define whether the payment is by setting the Instruction Priority (/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/) as follows:

   1. 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.

   2. HIGH: for urgent payments and physical point-of-sale payments (eg where the customer cannot leave the store until the payment is confirmed). If HIGH is used, the Destination PSP must 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.

See for further details.

Step 15: Send the pacs.008 to the Source IPS

1. 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).

2. The Source IPS will process the payment and then forward it to Nexus, following the process in .

[ON ROADMAP] Step 16: Be ready to respond to any Requests for Information from the Destination PSP

1. 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.

When the Destination PSP accepts the pacs.008 payment instruction, they will respond with a pacs.002 status report, 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.

pacs.002 Status for time-critical payments

For a pacs.008 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.

pacs.002 Status for non-time critical payments

For a pacs.008 with an instruction priority of NORM, two addition status codes are possible (in addition to ACCC and RJCT):

• ACWP (Accepted Without Posting): 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 must be followed up later with one of the following outcomes. The follow-up response must be sent within the Service Level Agreement 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 ACWC (Accepted With Changes) 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 resolve a sanctions screening alert within the time limit defined in the Nexus Scheme Rulebook.

  • This will be followed by a pacs.008 or 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.

If 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).

60-Second Summary

• Addressing: Nexus payments can be addressed using the same details that are valid for domestic payments, including:

  • IBAN (depending on the country)

  • Account Identifiers in conjunction with a Financial Institution Identification (either a BIC or a non-BIC Clearing System Member Identification, such as a routing number)

  • Proxies (also known as aliases) such as mobile numbers, email addresses or company registration numbers (depending on the country)

• Address Options & Address Inputs: A Source PSP (ie the sender’s PSP) can use the Nexus APIs to find out which address options (including proxies) are available in each country. Once the Sender has selected the Destination Country, the PSP’s app can call the relevant Nexus API and use the data returned to dynamically generate the addressing form in the app.

• Proxy resolution: Nexus connects to proxy directories in each country in the network. When a Sender provides a proxy (eg mobile number) for the Recipient, this will be sent through Nexus to the relevant proxy directory in the Recipient’s country. The proxy directory will reply with the Account Identification (account number) and Financial Institution Identification of the Recipient’s account.

• Account resolution: Nexus will also try to contact the Destination PSP (ie the recipient’s PSP) to request further information about the Recipient. The Destination PSP can choose whether or not to share any further information. Any information shared can increase the chances that sanctions screening and other compliance checks will pass without requiring manual intervention.

• Onboarding and setup: The Proxy Directory Operator (or IPSO, if the IPSO also operates the proxy directory) must inform Nexus of the address types available in its country when it first onboards to Nexus. It can do so through the Nexus Service Desk or through Nexus APIs.

• ISO 20022 and message translation: Nexus uses ISO 20022 messages (specifically acmt.023 and acmt.024) for proxy and account resolution requests and responses. Where an IPS or its member PSPs do not support these messages domestically, the IPSO is responsible for translating the domestic message to the Nexus standard and vice versa.

• Local implementation: In most countries, some changes may be needed to the domestic message format and the way that PSPs set up proxy resolution or account resolution requests.

Where proxies are not available, a payment can be addressed using either (a) International Bank Account Numbers (IBAN) or (b) local account numbers alongside a financial institution ID.

Addressing via IBAN

Nexus supports addressing by International Bank Account Numbers (IBAN) whenever the Destination Country accepts IBAN. IBAN is accepted in around 78 countries, but is not accepted in many major markets (such as Canada, Hong Kong, India, Singapore, and the USA).

Addressing via Account Identification and Financial Institution Identification

Nexus also allows payments to be addressed using an Account Identification (commonly called “account numbers”) and a Financial Institution Identification (such as a Business Identifier Code, BIC or a non-BIC Clearing System Member Id). Nexus is aware of the format of the Account Identification and Financial Institution Identification.

Identifying the Account

Account Identifications can vary significantly in format and length from country to country. In some countries, all Account Identifications have a fixed length, but in other countries the Account Identification can vary in length depending on the financial institution.

Identifying the Financial Institution

The ISO 20022 standard permits three types of Financial Institution Identification:

• Business Identifier Code (BIC) (most commonly used)

• Legal Entity Identifier (LEI)

• A domestic Clearing System Member Identification.

In some countries, financial institutions may have both a BIC and a Clearing System Member Identification, although only one or the other needs to be used in a specific payment instruction.

LEI can be used in addition to BIC or Clearing System Member Identification to provide further information about the financial institution. This can be useful to support compliance checks and sanctions screening.

Nexus allows payments to be addressed using any details that are valid in the Recipient’s country. These could include:

• International Bank Account Numbers (IBAN) (where used)

• Account Identification (account numbers) alongside a Financial Institution Identification (such as BIC or a non-BIC Clearing System Member Id)

• Proxies such as mobile phone number, email address or company registration number.

Nexus maintains a record of which payment address types are available in each country and provides this information to PSPs through the GET /countries/{countryCode}/addressTypes API operation.

Benefits of using proxies instead of account details

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 (for example) a phone number or email address than either (a) a Financial Institution Identification and Account Identification, or (b) an International Bank Account Number (which can be 20-32 characters).

• Reduces sharing of sensitive data: A payment can be addressed to the Recipient without the Recipient having to share sensitive personal details, such as their home address, or reveal where they hold their accounts.

• Provides confirmation of payee: Proxy directories 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 the account holder’s PSP). This helps to give the Sender confidence that they are sending funds to the correct account, as well providing a defence against fraud.

Where proxy services are unavailable

Proxy directories 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 IBAN (where accepted) and/or Account Identifications.

Nexus provides an API operation that returns a list of PSPs in a specific country along with their corresponding Financial Institution Identifications:

GET /countries/{countryCode}/fin-insts/psps

This can be used to generate a drop-down <select> menu item that allows the user to select the name of the PSP rather than entering the BIC manually.

This is useful for countries (such as the Philippines) that require the financial institution to be identified when using a proxy, or for countries (such as Singapore) where the convention is for the Recipient to share the full name of their PSP rather than the BIC.

In Nexus, each address type is defined by an ISO 20022 code:

• Account details will be described with the code IBAN (for IBAN) or ACCT (for Account Identifications).

• If ACCT is used, it will be necessary to also collect a Financial Institution Identification alongside the Account Identification. The Address Inputs API informs PSPs what information that needs to be collected.

• Proxies are defined by the ISO 20022 ExternalProxyAccountType1Code, taken from the

The table below lists the possible address type codes in Nexus. The most commonly accepted address types are bolded.

Table: Address types & codes

Nexus maintains a record of the address types (such as IBAN, Account Identifications or proxies) available in each country in the network, and the specific input fields that are required for each address type.

This information is initially provided by the IPSO or PDO in that country, at the point at which they are onboarded to Nexus. The information is then provided to PSPs through the Nexus APIs.

The data model for address types and inputs is described below, followed by examples.

Address inputs

In Nexus, each address type includes one or more address inputs. For example:

• An IBAN has only one address input (the IBAN field), because the IBAN itself combines information about the country, Financial Institution Id and Account Id.

• An ACCT will require two inputs: the Account Identification itself, plus a Financial Institution Identification such as a BIC (BICFI) or non-BIC Clearing System Member Id, such as sort code, routing number etc.

• A proxy normally requires only one input – the proxy identifier (such as a mobile phone number)

The Nexus APIs provide a list of the address inputs in a format that can be used by a PSP’s client application to dynamically generate the addressing form. Each input is defined in terms that are agnostic to programming frameworks (eg they are similar to common HTML attribute definitions), as shown in the table below.

The Nexus APIs also return some “hidden” inputs such as the account/proxy type code. These are fixed (ie not set by the Sender) and inform the Source PSP’s app how the address type should be processed. In some cases, the hidden information must be included in the acmt.023 message (such as the proxy type code when a proxy is used).

TABLE: Address Input structure

Example address types

Below is an example description of the address types for Indonesia. Please note the following:

• “id” would be automatically generated by the database. (In this example, human-readable IDs are given based on the country code and address type.)

• “code” defines the address type code

• “displayOrder” describes the order in which the proxy scheme recommends listing the address types when they are shown to the Sender (typically with mobile first, as the most common and user-friendly proxy type and the more obscure proxy types at the end of the list)

• For the ACCT address types “clearingSystemId” links to the internal Nexus ID of the instant payment system which accepts that address type

• For proxy address types, ”proxyDirectoryId” links to the ID of the proxy scheme that a proxy type belongs to.

Example address inputs

Below are three example descriptions of the address types. Firstly for a mobile phone proxy registered in Singapore, secondly for a Singaporean Account Identification, and third, for an IBAN registered in the UK.

Example mobile proxy

Note there are two inputs for a mobile proxy:

• The first is the text input field where the Sender will provide the mobile number of the Recipient. (This input starts with the “{“ prior to the first “attributes:”).

• The second is a hidden field which includes the MBNO address type (and proxy type) code. This addressTypeCode information will be required by the PSP to prepare the acmt.023 proxy resolution request.

Example account Identification

Note that there are three inputs for an Account Identification:

• The first input is the text input field where the Sender can input the Account Identification (accountOrProxyId)

• The second input is the text input where the Sender can input the Financial Institution Id (finInstId)

• The third is a hidden field which includes the code of the address type (“addressTypeCode”), which in this case is ACCC.

Example IBAN

For IBAN, only one text input is required, plus the hidden field addressTypeCode set to “IBAN”. The following example is for an IBAN to the United Kingdom.

List of PSPs

Nexus provides an API operation that returns a list of PSPs in a specific country along with their corresponding BICs:

GET /countries/{countryCode}/psps

This can be used to generate a drop-down <select> menu item that allows the user to select the name of the PSP rather than entering the BIC manually.

This is useful for countries (such as the Philippines) that require the financial institution to be identified when using a proxy, or for countries (such as Singapore) where the convention is for the Recipient to share the full name of their PSP rather than the BIC.

For usability, PSP app developers should enable the type-ahead feature that allows the user to start typing the PSP name to filter the list.

Masking of names

• The Recipient’s full name must be shared in full (unmasked) with the Source PSP to support sanctions screening. This information should be provided in the IdVrfctnReq/Rpt/UpdtdPtyAndAcctId/Pty/Nm element of the acmt.024 message.

• The Destination PSP may also share a ‘display name’, which could be the full name (unmasked) or the full name partially masked. This should be provided in the IdVrfctnReq/Rpt/UpdtdPtyAndAcctId/Acct/Nm element of the acmt.024 message.

• The Destination PSP is responsible for masking the name according to their own privacy and data protection preferences, policies or local regulations. Nexus will not mask or alter the information provided in the IdVrfctnReq/Rpt/UpdtdPtyAndAcctId/Acct/Nm element of the acmt.024 message.

In Nexus, each address type includes one or more address inputs. For example:

• An IBAN has only one address input (the IBAN field), because the IBAN itself combines information about the country, Financial Institution Id and Account Id.

• An ACCT will require two inputs: the Account Identification itself, plus a Financial Institution Identification such as a BIC (BICFI) or non-BIC Clearing System Member Id, such as sort code, routing number etc.

• A proxy normally requires only one input – the proxy identifier (such as a mobile phone number)

The Nexus APIs provide a list of the address inputs in a format that can be used by a PSP’s client application to dynamically generate the addressing form. Each input is defined in terms that are agnostic to programming frameworks (eg they are similar to common HTML attribute definitions), as shown in the table below.

The Nexus APIs also return some “hidden” inputs such as the account type code. These are fixed (ie not set by the Sender) and inform the Source PSP’s app how the address type should be processed. In some cases, the hidden information must be included in the acmt.023 message (such as the address type code when a proxy is used).

TABLE: Address Input structure

At this step, Nexus has access to account details for the Recipient, from one of two sources:

• An acmt.023 message from the Source PSP, which includes the Account Identification and Financial Institution Identification provided by the Sender, OR

• An acmt.024 response from the Destination Proxy Directory, which includes the account details associated with the proxy provided by the Sender.

If the Destination PSP is enabled to process acmt.023 requests, Nexus will send an updated acmt.023 to the Destination PSP to get verified information about the Recipient directly from the Destination PSP, as follows.

1. Nexus

Nexus will:

• look for the Agent Id in the Agent > FinancialInstitutionId element

• check whether that Agent is reachable through Nexus
• check whether the Agent is able to process account resolution requests. (Not all PSPs will be able to; this information will be recorded by Nexus when a new PSP is onboarded.)

• If the Destination PSP can accept account resolution requests, Nexus will:

  • update the Assignee for the message to the Destination PSP

  • forward the acmt.023 request message to the Destination PSP (via the IPS that is connected to that Agent).

• If the Destination PSP cannot accept account resolution requests:

  • If the Sender originally provided account details, Nexus will prepare an acmt.024 with the Report > Verification element set to “false” (since account resolution was not possible) and the appropriate Reason code (proposed to be AB08 – Offline Creditor Agent).

2. Destination PSP

The Destination PSP should use the account ID provided to look up the corresponding account.

• If the account is active, they should prepare an acmt.024 response and add (to the UpdatedPartyAndAccountIdentification block) the following information:

  • 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) or a partially obscured name, depending on the proxy service.

    • The Destination PSP is responsible for masking the name.

    • This value should be in the element UpdatedPartyAndAccountIdentification > Account > Name

• The Destination PSP should now prepare an acmt.024 response and send it to Nexus. The flow diagram below explains how the Destination PSP should prepare the message.

3. Nexus -> Source IPS -> Source PSP

In most IPS, a proxy (or "alias") cannot be used directly in a payment instruction (such as ISO 20022 pacs.008). Instead, the proxy must first be sent to the local proxy directory, via a proxy resolution request. The proxy directory service will then lookup and return the corresponding account details.

Proxy Directory Operators (PDOs) provide and maintain the databases which contain a list of proxies and the accounts and FIs that each proxy is associated with.

PDOs typically provide:

• A database of proxies and associated Financial Institution Identifications and Account Identifications

• 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 proxy resolution request to the proxy directory (ie sending a proxy and receiving back a Financial Institution Identification, Account Identification and name of the account holder)

The Source PSP will now receive an acmt.024 response message from Nexus.

1. The Source PSP will check the acmt.024 to see if the proxy or account resolution has been successful.

   • If the proxy or account resolution has failed, the Source PSP will display the reason to the Sender, based on the Reason Code provided. (For example: “This proxy is not associated with any account.”)

2. If the proxy resolution is successful, the Source PSP must:

   1. Check if the display name is provided in the acmt.024 response message (in the Account > Name element):

      1. If a display name is provide, the Source PSP should the display name to the Sender and ask them to confirm that this is the name they’re expecting to see (see Step 9 of the User Journey).

      2. If no display name is provided, the app should show the Sender a warning to the effect of “We were unable to check the name of the account holder. Please double-check the account details are correct before sending the payment.” The Sender may proceed with the payment at their own discretion.

Obligations of the Proxy Directory Operator

When the PDO is enabled through Nexus, the PDO needs to fulfil the following obligations:

Availability

• The PDO should have the ability to process proxy resolution requests, with the required availability (in principle 24/7/365), and with business continuity arrangements.

• The PDO should maintain availability of at least 99.5%.

Accuracy

• The PDO verifies, before a proxy can be 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 PDO guarantees that the proxy database will be kept current and changes made by proxy holders will be processed immediately.

• The PDO 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).

Data privacy and consent

• The PDO needs to ensure that all required consents have been collected for any information disclosed to and via Nexus. The method to do this should be compliant with local standards where the information is collected.

• The PDO will ensure that (contractual and implicit) privacy expectations of end users (both on the sending and receiving end of transactions) are met.

Compliance

• The PDO will keep track of queries processed for the purpose of providing an audit trail to relevant parties involved.

• The PDO establishes a secure channel with the Nexus Gateway for the protection of sensitive data.

60-SECOND SUMMARY

• Every cross-border, cross-currency payment requires an actor who is willing and able to exchange one currency for another. In Nexus, the entity providing this service plays the role of FX Provider (FXP).

• In some cases the Source PSP will act as FX Provider for its own payments. This can happen when:

  • the Source PSP is a participant in both the Source IPS and the Destination IPS for a specific corridor, or

  • the Source PSP holds the destination currency in an account with another PSP in the Destination Country, and that PSP is willing to act as Settlement Account Provider (described later) to the Source PSP.

• When a Source PSP acts as an FX Provider to itself, it can determine the FX rate for each payment and specify this FX rate in the payment instruction. It does not need to inform Nexus of the FX rate in advance.

• In other cases, the Source PSP will make use of a third-party FX Provider. A third-party FX Provider is any financial institution who provides FX conversion for the payments of another PSP. Source PSPs will need to use third-party FXPs when:

  • the Source PSP is not a participant in the Destination IPS, and

  • the Source PSP does not hold the destination currency in an account in the Destination Country.

• Third-party FXPs would be regulated financial institutions that are willing to accept the Source Currency from the sender and pay out the Destination Currency to the recipient.

• A third-party FX Provider must be a licensed and regulated entity but does not necessarily need to be a bank or non-bank Payment Service Provider.

• Third-party FX Providers must inform Nexus of the current rates at which they are willing to exchange one currency for another.

  • Nexus does not ask third party FXPs to bid on individual payments. Instead, Nexus uses the rates provided by FXPs to generate quotes which are provided to PSPs at the point that a Sender sets up a payment.

  • An FXP may choose to improve their rates for larger payments. For each currency, the FXP will inform Nexus of the tiers and thresholds at which better rates start to apply, and by how much the rate must be improved. Nexus will automatically calculate any improvements for larger payments and apply them to the quote given to the Source PSP.

  • An FXP may choose to improve rates for specific PSPs. The FXP will inform Nexus of the PSPs it wishes to deal with, and by how much rate must be improved for that FXP. Nexus will automatically calculate any improvements applicable to each PSP.

• Each payments corridor between two countries and currencies must have one or more third-party FX Providers, who are in competition with each other to provide the best rates.

• Settlement Account Providers (SAPs) are existing PSPs who are willing to provide accounts to:

  • third-party FX Providers who are not members of the IPS, and/or

  • Source PSPs in another country.

• SAPs are important because they ensure that FX provision in Nexus is not limited to large international banks who are members of two or more instant payment systems. SAPs help to open FX provision in Nexus to a wider range of financial institutions, including non-bank, non-PSP financial institutions who are not eligible to become IPS members.

• There may be multiple FXPs per IPS and per corridor, and multiple SAPs per IPS. The FXP is responsible for selecting the SAP they wish to use.

• Scheme adherence: Third-party FX Providers (ie those who provide FX to other PSPs) must be direct participants in the Nexus scheme. (Source PSPs who only provide FX conversion for their own payments – but do not act as a third-party FX Provider to other PSPs – may remain as indirect participants in Nexus, as per any other PSP.)

• Fees & Costs: Third-party FX Providers need to offer an FX rate that is sufficient to cover all their own costs and required profit margin. FXPs are not permitted to charge a fee or make a deduction from the value of the payment transferred.

  • If the FXP holds accounts at SAPs, it will need to pay fees to those SAP; these fees are negotiated bilaterally between the FXP and the SAP.

• Communication with Nexus: FXPs communicate with Nexus Gateways directly, sending API requests via HTTPS over the internet.

Following on from Step 1, assuming the Sender entered a proxy, the Source PSP will send Nexus an ISO 20022 acmt.023 message that includes the proxy details.

1. Nexus (Message Transformation)

Nexus will:

• look for the Country Code in the Assignee > Agent > PostalAddress > Country element

• identify the relevant proxy directory in that country, and

• update the Assignee to the BIC of the proxy directory (or its parent IPS Operator). This is the only change that is made to the message.

2. Nexus -> Destination Proxy Directory

Nexus will send the proxy resolution request to the Destination Proxy Directory Operator.

The message will be formatted as an ISO 20022 acmt.023 message. The PDO must be able to accept the message in this format. If the domestic proxy resolution message format is different, the IPSO is responsible for translating the message from the Nexus acmt.023 to the domestic format message before processing the proxy resolution request (See Messaging & Translation for further details.)

Scenario 1: No associated proxy

The Destination Proxy Directory should first check if the proxy is associated with an account.

If there is no associated account, the proxy directory should respond with an acmt.024 response including the appropriate error code in the Report > Verification > Reason > Code element. (See #toc143525641 for further information.)

Scenario 2: Proxy successfully resolved

If the proxy successfully maps to an account, the proxy directory should prepare and return an acmt.024 response message that contains, at a minimum:

• Account details, in the form of either:

  • an IBAN, OR

  • the Financial Institution Identification (eg BIC) AND the Account Identification of the linked account

• 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 stored in the element UpdatedPartyAndAccountIdentification > Party > Name.

  • Note that wherever possible, the full real name should be returned, as this information supports accurate and automated sanctions screening.

• a display name that can be shown to the Sender to allow them to confirm that 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) or a partially obscured name, depending on the proxy service.

  • This value should be in the element UpdatedPartyAndAccountIdentification > Account > Name

The proxy directory should send this response back to the Nexus.

See Step 3 below for details on how Nexus will handle this response.

Simple Overview

The diagram below shows the proxy and account resolution process at a high level.

Figure: Proxy & Account Resolution Flow Diagram (Simple Overview)

1. A Sender can enter either the Recipient’s proxy ID or account ID into their PSP’s app

2. The Source PSP will send this information to Nexus

3. If the Sender provided a proxy, Nexus will connect to the relevant proxy directory and request the corresponding account details

   1. The proxy directory will return the corresponding account details.

4. If either (a) the Sender provided an account ID, or (b) the proxy resolution response from the Proxy Directory includes the account ID, Nexus will:

   1. Check if the Destination PSP is able to accept account resolution requests.

      1. If so, Nexus will send an account resolution request to the Destination PSP

5. Nexus will combine the information from the proxy directory and the Destination PSP (if an account resolution request was sent), and send this back to the Source PSP

6. The Source PSP will check the information in the response:

   1. If a Display Name was provided, the Source PSP will ask the Sender to confirm that the payee is who they expect

   2. If no Display Name is provided, the Sender will be advised to proceed with the payment at their own risk

   3. If no other information is provided (such as the full name on the account), then the Source PSP will need to ask the Sender to provide this information so that the Source PSP can perform compliance and sanctions screening checks on the Recipient.

The rest of this section covers those steps in more detail.

1. When the Sender selects the Destination Country for a payment in their PSP’s app, the Source PSP will call the GET /countries/{countrycode}/addressTypes API operation, specifying the country code. Nexus will respond with a full list of address types for that country, including any proxy types, Account Identification formats and/or IBAN. (See Address Types for details.)

2. The Source PSP will show the Sender a form allowing them to select one of the possible address types, according to the details they were given by the Recipient.

3. The Sender selects an address type (eg the “Mobile” option on the form; in the case of a payment to Singapore, this would select the address type with the ID “SGMBNO”).

4. The Source PSP will call the GET /addressTypes/{addressTypeId}/inputs API operation to retrieve the input fields that are required for this address type.

1. The Source PSP’s app will use the address inputs to generate the app form to enter the address details

2. The Sender will enter the details that they were given by the Recipient (eg “+6580001234”).

3. The Source PSP’s app must validate that the address details entered by the Sender are in the correct format. These validation rules will be provided as regular expressions (regex) in the address inputs information provided by Nexus. This allows the PSP to validate the format of the data in-app, prior to any communication with Nexus or the proxy scheme.

4. If the Sender entered proxy details, the Source PSP will prepare an ISO 20022 acmt.023 message, following the usage guidelines for proxy resolution. The Source PSP will send the acmt.023 (or equivalent API request) to Nexus.

   1. See Step 2 for further steps on proxy resolution.

5. If the Sender entered account details, the Source PSP will prepare an ISO 20022 acmt.023 message, following the usage guidelines for account resolution. The Source PSP will send the acmt.023 (or equivalent API request) to Nexus.

   1. See Step 3 for further steps on account resolution.

Key Concepts: Rates vs Quotes

In Nexus, a rate refers to the exchange rate at which a third-party FXP is currently willing to exchange one currency for another. A rate is not specific to a single transaction or PSP. A rate is valid until an FXP sends an updated rate (or withdraws the rate entirely).

Nexus uses rates uploaded by the FXP (step 1 & 2 in the diagram above) to generate quotes which are provided to Source PSPs whenever they call the GET /quotes/ API operation (steps 3 & 4). Quotes are specific to the PSP making the request.

An overview of the process for generating and processing rates and quotes is given below. Further details are given in later sections.

Step 1: FXPs provide rates to Nexus

• An FXP must use the POST /rates/ API operation to inform Nexus of the (base) rate at which they are willing to swap the Source Currency (the Sender’s currency) for the Destination Currency (the Recipient’s currency).

  • A rate in Nexus describes the going rate or base 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.

Step 2: Nexus provides quotes to PSPs

When a Sender initiates a payment, they must define EITHER the amount they wish to send, in the Source Currency, OR the amount they wish the Recipient to receive, in the Destination Currency.

1. The Source PSP will then ask Nexus for quotes for that specific corridor and amount via the GET /quotes API

5. Nexus generates a list of payment-specific quotes with unique quote IDs - one quote ID for each FXP that has a business relationship with the Source PSP. Each quote describes a final exchange rate (with any improvements already applied) offered to a specific PSP by a specific FXP for a specific currency pair.

6. A PSP may select any a quote from any of the FXPs in the list. (The list will not include quotes from FXPs with which the PSP does not have a business relationship with.)

7. The final exchange rate provided to the Source PSP is the exchange rate that the FX Provider charges to the Source PSP. The rate is the ratio between the amount that the Source PSP pays to the FX Provider (in the Source Currency), and the amount the FX Provider pays to the Destination PSP (in the Destination Currency).

2. The Sender has an opportunity to accept those payment terms, or cancel the payment.

Step 3: Payments are processed against a specific quote

• 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.
• As the payment is processed, the FXP will:

  • Receive funds from the Source PSP via the FXP’s account at the Source SAP. (This payment is processed through the Source IPS.)

  • Pay out funds to the Destination PSP from the FXP’s account at the Destination SAP. (This payment is processed through the Destination IPS.)

• When the payment is completed, the FXP holds more of the Source Currency in its account at the Source SAP, and less of the Destination Currency in its account at the Destination SAP.

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 back 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.

The obligations of PSPs when using the proxy directory are defined in the Nexus Rulebook. In particular:

• Appropriate use of the service: The Source PSP is obliged to only send proxy resolution requests for the purpose of initiating a payment. However, the Source PSP is not obliged to complete a payment after initiating a proxy resolution (for example if the Sender decides not to proceed with the payment).

• Restricted use of the data: When data is returned in response to a proxy resolution request, the PSP must use that data only for the purpose of processing this transaction, and not for any other purpose.

• Confirmation of payee: Where the Recipient’s name is provided to the Source PSP (by the Proxy Directory or Destination PSP), the Source PSP must display this name 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 chance of the proxy being used for fraud.

• Prevention of abuse:

• The Source PSP should monitor the number of proxy resolution 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, for example, five different proxies in a short period without initiating a payment (ie a rate limit on proxy resolution requests).

• When sending acmt.023 proxy or account resolution requests, the Source PSP should include an unique Identification for the Sender which will allow the Proxy Directory Operator to identify whether multiple requests are initiated by the same individual in short succession. See for the correct placement of this Identification.

Eligibility to be an FXP

A third-party FX Provider must be a licensed financial institution that is:

1. Willing to quote FX rates for specific currency pairs between Nexus countries (ie. from currency A in IPS-A to currency B in IPS-B). These rates will be shown to Source PSPs that have a business relationship with the FXP, when one of those PSPs calls the GET /quotes/ API.

2. Able to hold funds in at least two instant payment systems (IPSs), either directly through their own membership of the IPS, or indirectly through an account they hold with a Settlement Access Provider (SAP). (See .)

3. Licensed to perform the role as FX Provider by the regulator in their home jurisdiction (if applicable) and compliant with all relevant regulatory requirements in that jurisdiction.

4. Compliant with any local regulatory requirements that apply to each currency that the FX Provider offers (including acquiring local licenses where required, eg for currencies with capital flow measures)

Joining the Nexus Scheme

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.

The FXP must provide the Nexus Scheme Organisation with evidence that the FXP has the necessary licenses to provide FX for their chosen currency pairs.

Onboarding with Nexus and setting up reference data

At the point of onboarding, an FXP must inform Nexus of:

1. The currency pairs that it wishes to quote for.

2. The PSPs with which the FXP has a business relationship (ie is willing to offer FX conversion services to). (See .)

3. The IPSs in which it is able to hold funds (either through membership or via Settlement Access Providers – see next section)

4. For each IPS where the FXP is a member (ie where the FXP acts as SAP to itself):

   1. the FXP's Financial Institution Identification (such as BIC, LEI or Clearing System Member Identification) in that IPS. This is used to identify the FXP's account at the IPS, through which Nexus payments will flow.

   2. the account identifier/number of an account at the FXP (used for internal accounting of transactions related to Nexus payments)

5. For each IPS where the FXP uses an SAP:

   1. the Financial Institution Identification (such as BIC, LEI or Clearing System Member Identification) of the FXP's SAP, and

   2. the account identifier/number of the FXP's account at that Settlement Access Provider (which will be credited/debited by the SAP as appropriate)

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 /quotes/{quoteId}/intermediaryAgents/ API operation with a valid quote ID.

Integrating with Nexus

FXPs will need to develop (or adapt) their systems to:

• Submit information about rates, tier-based improvements, PSP-based improvements and new business relationships to the Nexus APIs

• Accept notifications of completed payments from the Nexus APIs

• Process these notifications and (if necessary) integrate the information into the systems that track their liquidity in different currencies

• Revise their rates as needed in order to manage their liquidity

The PDO must provide Nexus with reference data on the available address types and input fields

Nexus needs to be aware of the different (such as IBAN, account, mobile) and available in each country, so that it can provide this information to Source PSPs through the Nexus APIs. Therefore when a new IPSO (or proxy service) is onboarded with Nexus, the IPSO must provide Nexus with reference data describing each address type and the input fields (address inputs) for that address type. This information can be provided via the Nexus Service Desk or APIs.

The IPS Operator is responsible for ensuring that the data is kept up to date.

PDO must onboard with the local IPS Operator

The Nexus Scheme expects the IPS Operator to take on the responsibility for connecting its instance of the Nexus Gateway to the domestic proxy directory, particularly where:

• The IPS Operator and the PDO are the same entity, AND/OR

• In each country that the IPS Operator provides payment services to, there is only one PDO

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 may 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 Access Provider (SAP), who provide FXPs (or PSPs) who are not themselves members of an IPS with accounts which can send and receive payments through a specific Instant Payment System (IPS)

When FX is provided by the Source PSP

In some cases, the Source PSP will act as FXP for its own payments; this may happen when:

• the Source PSP is a participant in the IPS of the Destination Country, OR

• the Source PSP holds an account at a PSP in the destination country, and that PSP is willing to act as a Settlement Access Provider.

When FX is provided by a third-party FX Provider

In other cases, the Source PSP will make use of a third-party FXP; this is more common when the Source PSP only operates in one country and does not hold funds in the destination country.

Third-party FXPs would be regulated financial institutions that are willing to accept the Source Currency from the Sender and pay out the Destination Currency to the Recipient.

Third-party FXPs inform Nexus of the current rates at which they are willing to exchange one currency for another. They compete to offer the best rates for a specific corridor, helping to ensure a competitive market.

Each payments corridor between two Nexus countries and currencies will have one or more third-party FX Providers, who are in competition with each other to provide the best rates.

Playing multiple roles in Nexus

A single financial institution may choose to play one or more roles in Nexus (subject to eligibility). The role an institution plays may vary depending on the currency pair and specific payment.

The table below shows the exhaustive combination of roles that an FXP may play. When the Source PSP and the FX Provider are separate entities, the Source PSP is using a Third-Party FX Provider.

(Each box shows a distinct financial institution.)

Two special cases have a significant impact on the way that the FXP acts:

• SPECIAL CASE 1: Source PSP acts as FXP for its own payments (scenarios 10, 11 and 12 in the diagram below):

  • A PSP that holds the Destination Currency in an account at a Destination SAP may act as FX Provider for their own payments.
• SPECIAL CASE 2: An FXP and (one or both) SAP(s) are the same entity (scenarios 5-12 below):

Accessibility for smaller or non-bank FXPs

Nexus is designed to enable a wide range of actors to play the role of FX Provider. For example, the use of Settlement Access Providers enables institutions who are not members of an IPS to access that IPS and provide FX via Nexus. This ensures that FX provision is not limited to the largest international banks (who are more likely to be members of multiple IPSs). It also makes it more likely that there is FX provision for lesser-used or “exotic” currency pairs.

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 provides FX conversion to that PSP.

Once the FXP has completed due diligence on a PSP, it must inform Nexus (via the Nexus administration portal or Nexus APIs) that it is willing to provide FX to that PSP.

Streamlining the PSP onboarding process

FXPs must accept the Wolfsberg (CBBDQ) from PSPs.

The Wolfsberg CBDDQ is a standardised 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.

Streamlining the PSP onboarding process in this way is important 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 may wish to apply to be onboarded with multiple FXPs, and each FXP may wish to onboard multiple PSPs.

If every FXP imposes a different KYC/KYB process upon PSPs, the cost to a PSP of onboarding with an FXP would be higher, which could:

• discourage FXPs from onboarding smaller PSPs as the benefits of doing so (potential 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.

Mandatory use of the Wolfsberg CBDDQ will help to streamline this process.

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’ or base rate at which an FXP is willing to swap one currency for another.

• The base rate is not specific to a single transaction. FXPs are not asked to quote or bid on individual transactions (which would cause significant traffic and demand to their own systems). 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.

• A rate may be improved depending on the size of the transaction (tier-based improvements) and/or the PSP requesting the quote. (See and )

• The final rate provided in a quote to the Source PSP is the rate that the FX Provider charges to the Source PSP.

  • The final rate is the ratio between the amount the FX Provider pays to the Destination PSP and the amount that the Source PSP pays to the FX Provider.

  • The Source PSP may charge the Sender more than they transfer to the FX Provider. The different between the amount debited by the Source PSP from the Sender’s account and the amount transferred from the Source PSP to FXP is known as the Source PSP Deducted Fee. (See .)

Updating rates

A rate provided by an FXP continues to apply until the FXP sends a new rate to the POST /rates/ API.

When a new rate is submitted:

• The previous rate is automatically expired

• Any already-issued quotes based on the previous rate are set to expire in 600 seconds (10 minutes) from now, meaning that a payment instruction using one of those quotes must reach Nexus within 600 seconds or it will be rejected. (see and )

Source PSPs who call the GET /quotes API are only shown the most recent (unexpired) rate from each FXP.

Structure of a rate

Within the Nexus FX service’s internal database, each rate contains the following information.

Rate uniqueness

A rate is unique to:

• A specific FXP, AND

• A pair of Intermediary Agent Accounts in two separate IPSs

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 A➔B is set independently of the rate for payments from B➔A. The rate for B➔A is not simply the reciprocal of the rate for payments from A➔B

  • RateB➔A ≠ 1 / RateA➔B

Withdrawing a rate

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 may 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. (For audit and traceability purposes, the rate is never actually removed from the underlying database.)

Even when an FXP withdraws their rates, Nexus will continue to honour any quotes issued against that rate if the quote was issued within the last 10 minutes. This means that after withdrawing rates for a particular currency pair, it may take up to 10 minutes for payments to stop being processed against the FXP’s accounts at the Source and Destination SAP.

A third-party 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:

1. membership of the IPS, or

2. through an account held with an existing IPS member (who plays the role of “Settlement Access Provider” to the FXP).

Option 1: IPS Membership

In this model, the FXP is a member of the IPS. This means that:

1. the FXP already holds a settlement account at the central bank which provides settlement services to the IPS. This account may currently be used for processing domestic instant payments.

2. the funds in this settlement account can also be used for processing Nexus payments (in addition to domestic payments)

3. the FXP is able to directly submit payment instructions to the IPS

In this case, the FXP can act as an SAP to themselves.

Option 2: Indirect access via Settlement Access Providers

FX Providers who are not a member of an IPS may choose to access the IPS indirectly via a “Settlement Access Provider” (SAP). In this model an FXP holds an account at an existing IPS member. This means that:

1. The IPS member (an existing PSP) that provides the account to the FXP plays the role of SAP to the FX Provider.

2. 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.)

3. The SAP makes and receives payments on behalf of the FXP.

Choosing between Access Models

For each FXP, the choice of access model may differ depending on the country:

1. 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 arrange indirect access via an SAP. Other non-banks, such as non-bank FX dealers, are usually not eligible for access in any IPS.

2. 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 FXP may use different options in different countries. For example, they could have direct membership in one IPS and indirect access in another IPS to facilitate an FX currency pair.

In general, an FX Provider is more 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.

Examples

In the diagram below, the FXP 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 via 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 this FXP.

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.

The FXP below 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.

​

Revenue model for FXPs

As described in the Nexus Scheme Rulebook, FXPs are not permitted to:

• make a deduction from the value of a Nexus payment as it flows through the FXP's accounts, or

• charge a separate fee (“Invoiced Fee”) to PSPs for the FX service they provide.

Therefore FXPs must set the exchange rates they offer via Nexus at a level that provides for all their own costs plus their expected profit margin.

Costs incurred by FXPs

Key costs incurred by FX Providers will include:

• The initial technical cost incurred by the FXP to integrate with Nexus

• The costs of acquiring a particular currency (either purchased via wholesale FX markets, or borrowed, for example if the SAP provides the FXP with a line of credit)

• The costs charged by Settlement Access Providers for account provision (if the FPX is not a member of the IPS in question)

• All other costs of operation, onboarding PSPs, regulatory compliance etc.

Ensuring a competitive FX market

Nexus is designed to ensure a competitive FX market:

• FX Providers are in competition with each other to provide the best exchange rates for a given currency pair.

• 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 as a whole.

To have competitive pricing, there needs to 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.

The Nexus Scheme Rulebook provides detailed obligations for FX Providers. At a high level, these obligations include:

Compliance

FX Providers must comply with all applicable regulations in the jurisdiction they are based in, as well as any applicable regulations in the jurisdiction to which they are providing FX.

Sanctions screening

Unless otherwise required by a specific country’s regulatory regime, a third-party FXP is not obliged to perform sanctions screening on individual Nexus payments. The FXP’s counterparty is the Source PSP to whom they sell the Destination Currency, and the FXP does not deal with (or have information on) the Sender or Recipient.

However, when an FXP is a member of an IPS and therefore acts as SAP to themselves, the entity is responsible for screening the payment against applicable sanctions lists in their role as SAP, subject to local regulations. (See .)

Minimum commitment

FXPs must commit to providing FX to Nexus for a certain minimum duration (to be specified in the Nexus Scheme Rulebook) 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 Nexus Scheme Rulebook defines the process and minimum notice period for withdrawing from the scheme.

Market maker role

In general, FX Providers are expected to play a similar role to that of a market maker; this means that they are expected to always provide a quote for the payment corridors that they provide. If they do not wish to be committed for new payments, they may 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 expectation 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 FXPs 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 (Mon-Fri) and ultimately 24/7 (including weekends).​

PSP-based improvements

FX Providers may also want to offer improved rates to specific PSPs. In Nexus this works as follows:

• An FXP may define the PSPs to which it wishes to offer improved rates

• For each PSP, the FXP may define how much the base rate must be improved, in basis points.

• This improvements applies to all quotes issued to that PSP by the FXP, for all currencies.

• When a Source PSP calls the GET /quotes API, Nexus will review the table of relationships between FXPs and PSPs, and extract any relevant preferential rates for that PSP.

• Nexus will then apply the relevant improvement to the FXP's base rate.

• An FXP may choose not to set any PSP-based improvements. If no PSP-based improvement is set for a specific PSP, the base rate will apply.

TABLE: Example PSP-based improvements

60-SECOND SUMMARY

Nexus payments are processed through the domestic instant payment systems in the Sender and Recipient’s countries. All funds movement takes place within the two IPS.

Payment Process:

• Within the Nexus payment flow, a payment is cleared and settled in both the Source Country and the Destination Country sequentially.

• Failures at any point will lead to the payment being reversed and funds returned to the Source PSP and Sender.

Compatibility with different IPS settlement models:

• Nexus is compatible with different domestic settlement models, including deferred net settlement and real-time gross settlement in central bank money.

• Nexus is compatible with both 4-step as well as 5-step instant payment clearing and settlement processes. (In a 5-leg payment, an additional confirmation of settlement message is sent to the Creditor Agent.)

Ensuring certainty of settlement: In all cases Nexus requires that each IPS ensures settlement certainty, so that:

• (a) Nexus payments will always be honoured, even in the event of the insolvency of any participant while the payment is being processed, and

• (b) Nexus payments can be reversed in the case that any participant rejects the payment instruction (for any reason).

Certainty of settlement can be ensured through any effective mechanism, including: immediate transfer of central bank money; pre-funding; funds reservation; or loss-sharing agreements.

Use of ISO 20022: Nexus exclusively uses ISO 20022 standard messages (and APIs) to communicate with IPSs. IPSs who do not use ISO 20022 for domestic messages must translate those messages according to the Nexus guidelines before sending messages to Nexus, and after receiving messages from Nexus. Nexus does not provide a translation service; this must be handled by the IPS. See Messaging & Translation for further detail.

Message tracking: Every pacs.008 payment instruction must have a Unique End-to-End Reference (UETR) to allow tracking and investigation of the payment. If the Source PSP does not add this UETR, it must be added by the IPS before the message is sent to Nexus. See #toc159257057

Exceptions and disputes: Nexus provides a Service Desk to help tracking of investigations, recall requests and disputes. In the first release of Nexus, these cases must be managed manually. In a future release, Nexus will add support for the relevant ISO 20022 messages to enable these cases to be processed via automatic communication between each PSP’s systems (although human intervention may still be needed to make decisions based on the information provided through these messages).

• The Nexus Scheme does not set a minimum or maximum limit on transaction values.

• Each IPS operator may choose to set their own maximum payment value for Nexus payments, at their discretion (or depending on any domestic regulatory requirements).

Setting a Maximum Payment Value at the IPS Level

• Each IPS operator must inform Nexus of the value limit (if any) applicable in their IPS via the Nexus Service Desk.

• This Nexus-specific maximum value may be lower than the maximum set for domestic payments, at the IPS operator's discretion.

• Nexus will share information about the value caps for each country with the PSPs making payments to that country, via the GET /countries/ API operation.

How Nexus applies IPS-defined maximum value limits

• Nexus will also apply IPS-specific value limits when generating quotes in response to requests from PSPs.

• Since both IPSs in a Nexus payment can apply limits, Nexus will apply the lower of the two limits, at the exchange rate given in a particular quote. (See Quotes.)

Limits set by PSPs

• A Source PSP may choose to apply their own (lower) limit on the value of payments which can be sent. They can do this by simply limiting the value that the Sender can enter into the payment instruction, and not sending payments over this value.

  • Source PSP-specific limits are entirely the responsibility of the PSP in question.

  • Source PSP-specific limits are not known to Nexus and will not be enforced by Nexus.

• A Destination PSP may choose to refuse payments that are above a certain value, although this should be avoided whenever possible due to the negative impact on user experience.

  • Nexus is not aware of any value limits set by a Destination PSP and is therefore unable prevent payments over that cap being sent to the Destination PSP.

  • In the case that the Destination PSP receives a payment above their own value limit, the Destination PSP must reject the pacs.008 payment instruction with the appropriate reason code.

Nexus does not prescribe the internal booking flow for PSPs (ie how and when they should debit the Sender/Debtor Account). However, payments submitted to Nexus cannot be stopped or recalled, meaning that payments in error can only be recovered by manual communication between the Source PSP and Destination PSP. Therefore the Source PSP should always ensure the payment can be processed on the account before sending the transaction.

This results in the following options for the Source PSP:

Option 1: Reservation followed by Booking

• The Source PSP validates the payment and make a funds reservation on the Sender’s account.

• The funds reservation must be upheld until the final response is received from the Source IPS.

• When the response indicates successful processing of the payment (either an ACCC or an ACWP response), the funds reservation results in a debit booking on the Sender’s account.

Option 2: Booking with optional reversal

• The Source PSP can also opt for the option of debiting the Sender’s account before sending the instruction to the Source IPS for further processing.

  • If the response is received with an ACCC or ACWP code, no further action is required.

  • In case the response indicates a RJCT code, the original debit on the Senders account must be reversed, resulting in a debit and credit booking.

A payment can be time critical when the use case requires near-instant confirmation of rejection, for example when paying in-store, or non-time critical, for example when using Nexus for bill payments.

Whether a payment is time-critical or not is flagged using the pacs.008 Instruction Priority element(/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/).

In general the Source PSP should set the Instruction Priority, based on what it knows about the type of payment that is being initiated. For example, payments to a retail business, or initiated by scanning a QR code, are more likely to be time sensitive. If the Sender is asked to select the priority, they should be informed of the implications of their choice.

Time-critical payments

Time-critical payments must only be accepted by the Destination PSP when the Destination PSP is (a) able to perform real-time sanction screening, AND (b) if the screening is OK, the Destination PSP is able to credit the recipient in real time.

• The Source PSP should set the pacs.008 Instruction Priority to HIGH

• Within the timeout SLA of the Destination IPS, the Destination PSP must process the payment and return a pacs.002 with one of the following status codes:

  • ACCC – accepted and credited to recipient

  • RJCT – rejected

  • BLCK - funds blocked and will not be returned (due to suspicious or illicit activity)

• The pacs.002 will flow from the Destination PSP to Destination IPS, to Nexus, to the Source IPS and finally to the Source PSP.

• (Note: The Source SAP may only respond with ACCC or RJCT.)

Non-time critical payments

• The Source PSP should set the pacs.008 Instruction Priority to NORM (pacs.008 element /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/ ) when the payment is non-time-critical.

• Within the technical timeout SLA of the Destination IPS, the Destination PSP must process the payment and send back a pacs.002 with one of the following status codes:

  • ACCC – accepted and credited to recipient

  • RJCT – rejected

  • BLCK – funds blocked and will not be returned (due to suspicious or illicit activity)

  • ACWP – accepted without posting to the Recipient’s account

• The pacs.002 will flow from the Destination PSP to Destination IPS, to Nexus, to the Source IPS and finally to the Source PSP.

• (Note: The Source SAP may only respond with ACCC or RJCT.)

If the Destination PSP responds with the status code ACWP, the Destination IPS must still complete the transfer between the Destination SAP and Destination PSP, but the Destination PSP will not immediately credit funds to the Recipient.

Following up on an ACWP response

When the Destination PSP responds with ACWP, the Destination IPS will process the payment in the same way it would an ACCC, and send a confirmation to Nexus. 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.

After the Destination PSP responds with ACWP, then within the time limit set in the Nexus Scheme Rulebook, the Destination PSP must respond with:

• ACCC (Accepted and Credited to Creditor Account) – funds now credited to the recipient

• BLCK (Blocked) – funds blocked and will not be returned (due to suspicious or illicit activity)

• ACWC (Accepted with Changes) with status reason code (StsRsnInf/Rsn/Cd) RUTA (Return upon Unable To Apply) - in this case, the Destination PSP was not able to reach a definitive answer within the time limit specified in the Nexus Scheme Rulebook. The Destination PSP must initiate a new Nexus payment to return the funds to the Source PSP

When Nexus successfully processes a payment which references an FXP’s quote, Nexus will send a notification to an API endpoint provided by the FX Provider.

The notification will give the following details:

• Date and time of payment

• Unique End-to-End Transaction Reference (UETR) of the underlying payment

• Currency & amounts:

  • Source Currency

  • Amount in Source Currency

  • Destination Currency

  • Amount in Destination Currency

  • Exchange Rate

• Parties:

  • Source PSP (Debtor Agent)

  • Destination PSP (Creditor Agent)

  • (No Personally Identifiable Information on the Debtor and Creditor)

• Audit trail:

  • ID of the FXP’s rate on which this quote was based

  • ID of the tier (if applicable) that applied to the quote

  • ID of the relationship record which links the PSP and FXP (which includes the PSP improvement, if any)

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.

This page describes the arrangement of deposit or IPS settlement accounts in Nexus, and other relationships between participants.

Deposit account relationships

There are four key deposit-account relationships in Nexus:

• The Sender holds a deposit account (ie checking/current account) at the Source PSP

• The Recipient holds a deposit account at the Destination PSP

• Depending on an FXP's access to the IPS, the FXP may hold:

  • A deposit account denominated in the Source Currency at a Source Settlement Access Provider (SAP)

  • A deposit account denominated in the Destination Currency at the Destination SAP.

IPS Settlement Accounts

• The Source PSP and Source SAP hold IPS settlement accounts, recorded at the Source IPS.

• The Destination SAP and Destination PSP hold IPS settlement accounts, recorded in the Destination IPS.

• (In practice, the IPS settlement accounts are actually held at the respective central banks, but the IPS will process transactions to and from those accounts, either in real time or at the end of a settlement cycle.)

Relationships between participants

The relationships between the different parties during the processing of a Nexus payment are:

• The Source PSP has already onboarded with one or more FXP(s) and has selected this FXP for this Nexus transaction

• The FXP has opened an account at a Source SAP and a Destination SAP in the applicable currencies (unless the FXP is itself a member of either IPS - see Accessing Instant Payment Systems)

• The Source IPS has onboarded the Source PSP and the Source SAP

• The Destination IPS has onboarded the Destination SAP and the Destination PSP

The Destination Country processing flow is shown below:

The Destination Country payment process follows the following steps:

The sending payment process follows the following steps:

Tier-based improvements for larger transactions

In Nexus a specific FXP may offer better rates for larger transactions. This works as follows:

• For each specific Source Currency, the FXP may 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) must be improved, in basis points.

• For payments smaller than the lowest tier, the base rate (provided when the FXP submits a rate to the POST /rates/ API) applies.

WORKED EXAMPLE: Tier Improvements

In this example, the Source Currency is Euros. The maximum payment permitted through the TIPS payment system is EUR 100,000. FXP-A may 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 + ((Improvement in 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.

Validations by Participants

During the payment process described in there are a number of validations of the payment:

• The Source PSP will validate whether the Sender has sufficient balance (or an overdraft) on its account to honour the payment

• The Source IPS will validate whether the Source PSP has sufficient funding in its settlement account to cover its settlement obligations to the Source SAP

• The Destination SAP will validate whether the FXP has sufficient balance on its account at the Destination SAP

• The Destination IPS will validate whether the Destination SAP has sufficient funding in its IPS settlement account to cover its settlement obligation to the Destination PSP

Validations by Nexus

When Nexus receives the pacs.008 payment instruction from the Source IPS, it will validate certain details before forwarding it to the Destination IPS.

Validation of Amounts

• Nexus validates that the amount of the payment does not exceed the value limit of the IPSs at two points:

  • firstly, when for PSPs (Nexus applies both the Source IPS and Destination IPS value limits)

  • secondly, when Nexus transforms the Interbank Settlement Amount in a pacs.008 before it is forwarded to the Destination IPS (Nexus will only validate the Destination IPS cap, as any payment forwarded by the Source IPS must logically be within the Source IPS’s own cap.)