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 [to follow]

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

As shown in , 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

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:

   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.

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

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 pacs.008 payment message.

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

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.

• Effective Rate – the effective rate paid by the Sender, with potential fees included. See Quotes for further explanation.

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.

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.

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

The Source PSP should now send the proxy or account details provided by the Sender as an ISO 20022 acmt.023 message. This triggers the following steps:

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

2. Nexus will follow the steps outlined in Proxy & Account Resolution Process to contact the relevant proxy directory and/or Destination PSP.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

Any FX Provider that meets the eligibility requirements and adheres to the Nexus Scheme may provide FX conversion to Nexus payments.

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.

  • In this case the Source PSP does not need to request a quote from Nexus. They may instead define the FX rate they wish to apply to the payment. The Source PSP must follow a special process when preparing the payment instruction – see Payment setup for PSPs who provide their own FX.

• SPECIAL CASE 2: An FXP and (one or both) SAP(s) are the same entity (scenarios 5-12 below):

  • An FXP that is a member of either the Source or Destination IPS may also act as Settlement Access Provider to themselves. (See Accessing Instant Payment Systems)

  • In this case, everything in this guide applies as normal, but in addition, the obligations that apply to an SAP also apply to the FXP, in their capacity as an SAP. (See Settlement Access Provision.)

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.

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 many countries with instant payment systems (IPSs), payments can be addressed using “proxies” (or “aliases") in place of Account Identifications. A proxy (or alias) is any string of text that can be linked to a specific bank account. Commonly accepted proxies include:

• Mobile phone numbers

• Email addresses

• National ID numbers

• Company incorporation numbers

Nexus allows cross-border payments to be addressed using proxies. In principle, any proxy that is valid for domestic payments should also be valid for Nexus payments. (This is dependent on the relevant proxy service provider being onboarded and connected to Nexus.)

Different countries support different types of proxies. The table below shows some examples.

Explainer: Example proxy schemes

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

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

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 relevant Proxy Directory Operator (PDO) recommends listing the address types when they are shown to the Sender

  • Typically mobile phone number would be listed first, as it is 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 ISO 20022 External Clearing System Identification Code of the instant payment system which accepts that address type. (Example values are given below.)

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

{
  "addressTypes": [
    {
      "id": "IDACCT",
      "countries": [
        "ID"
      ],
      "code": "ACCT",
      "clearingSystemId": "BIFST",
      "displayOrder": 3
    },
    {
      "id": "IDEMAL",
      "countries": [
        "ID"
      ],
      "code": "EMAL",
      "proxyDirectoryId": "IDPROXY",
      "displayOrder": 2
    },
    {
      "id": "IDMBNO",
      "countries": [
        "ID"
      ],
      "code": "MBNO",
      "proxyDirectoryId": "IDPROXY",
      "displayOrder": 1
    }
  ]
}

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.

{
  "id": "SGMBNO",
  "inputs": [
    {
      "attributes": {
        "name": "accountOrProxyId",
        "type": "tel",
        "pattern": "^\\+(?:[0-9] ?){6,14}[0-9]$",
        "placeholder": "+6581234567",
        "required": true
      },
      "iso20022Path": {
        "acmt023": "/Document/IdVrfctnReq/Vrfctn/PtyAndAcctId/Acct/Prxy/Id",
        "pacs008": null
      },
      "label": {
        "code": "MBNO",
        "title": {
          "en": "Mobile phone number, including the country code",
          "de": "Mobiltelefonnummer, einschließlich der Landesvorwahl"
        }
      }
    },
    {
      "attributes": {
        "name": "addressTypeCode",
        "type": "hidden",
        "value": "MBNO",
        "required": true
      },
      "iso20022Path": {
        "acmt023": "/Document/IdVrfctnReq/Vrfctn/PtyAndAcctId/Acct/Prxy/Tp/Cd",
        "pacs008": null
      }
    }
  ]
}

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 Identification (finInstId)

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

{
  "id": "SGACCT",
  "inputs": [
    {
      "attributes": {
        "name": "accountOrProxyId",
        "type": "number",
        "pattern": "^\\+\\d{9,10}$",
        "placeholder": "1234567890",
        "required": true
      },
      "iso20022Path": {
        "acmt023": "/Document/IdVrfctnReq/Vrfctn/PtyAndAcctId/Acct/Id/Othr/Id",
        "pacs008": "/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CrtrAcct/Id/Othr/Id"
      },
      "label": {
        "code": "ACCT",
        "title": {
          "en": "Account number, 9-10 digits",
          "de": "Kontonummer, 9-10 Ziffern"
        }
      }
    },
    {
      "attributes": {
        "name": "finInstId",
        "type": "text",
        "pattern": "^[A-Z]{6}[0-9A-Z]{2}([0-9A-Z]{3})?",
        "placeholder": "AAAASGAA or AAAASGAA123",
        "required": true
      },
      "iso20022Path": {
        "acmt023": "/Document/IdVrfctnReq/Vrfctn/PtyAndAcctId/Agt/FinInstnId/BICFI",
        "pacs008": "/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CdtrAgt/FinInstnId/BICFI"
      },
      "label": {
        "code": "BICFI",
        "title": {
          "en": "BIC of the Creditor's Bank or Payment Service Provider",
          "de": "BIC der Kreditorbank des Payment Service Providers"
        }
      }
    },
    {
      "attributes": {
        "name": "addressTypeCode",
        "type": "hidden",
        "value": "ACCT",
        "required": true
      },
      "iso20022Path": {
        "acmt023": null,
        "pacs008": null
      }
    }
  ]
}

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 (GB).

{
  "id": "GBIBAN",
  "inputs": [
    {
      "attributes": {
        "name": "accountOrProxyId",
        "type": "number",
        "pattern": "^GB[0-9]{2}[A-Z]{4}[0-9]{14}$",
        "placeholder": "GB29 NWBK 6016 1331 9268 19",
        "required": true
      },
      "iso20022Path": {
        "acmt023": "/Document/IdVrfctnReq/Vrfctn/PtyAndAcctId/Acct/Id/IBAN",
        "pacs008": "/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CrtrAcct/Id/IBAN"
      },
      "label": {
        "code": "IBAN",
        "title": [
          {
            "en": "International Bank Account Number",
            "de": "Internationale Bankkontonummer"
          }
        ]
      }
    },
    {
      "attributes": {
        "name": "addressTypeCode",
        "type": "hidden",
        "value": "IBAN",
        "required": true
      },
      "iso20022Path": {
        "acmt023": null,
        "pacs008": null
      }
    }
  ]
}

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

Nexus needs to be aware of the different address types (such as IBAN, account, mobile) and address inputs 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

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 Messaging & Translation for the correct placement of this Identification.

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)

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.

Using with Account Id

An account ID (ACCT) only specifies the account, not the financial institution that holds that account. Therefore when the ACCT address type is selected, the Account Identification must always be used in conjunction with one of the Financial Institution Identification types in the table below.

Using with a Proxy

TABLE: Financial Institution Identification Types

The following Financial Institution Identification types are defined in ISO 20022.

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.

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

  • If not, Nexus will prepare an actm.024 with the Report > Verification element set to “false” (since it is not possible to proceed with the payment) and the appropriate Reason code (AGNT, Incorrect Agent – see #toc143525641).

• 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 a proxy, Nexus will forward the acmt.024 that was received from the Destination Proxy Directory in Step 2

  • 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 does not exist or is inactive, they should return an acmt.024 with the Report > Verification element set to “false” and the appropriate Reason code (such as AC01, AC04, AC06 – see #toc143525641).

• 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

Nexus will forward the acmt.024 response (from the Destination PSP) to the Source PSP, via the IPS. See Step 4.

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.

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

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

      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.

• As per normal practice, the Recipient’s full name must be shared in full (unmasked) with the Source PSP to support sanctions screening.

  • This information should be provided by the Proxy Directory or Destination PSP in the IdVrfctnReq/Rpt/UpdtdPtyAndAcctId/Pty/Nm element of the acmt.024 message. See

• The Proxy Directory or 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 Proxy Directory or Destination PSP is responsible for masking the name according to their own privacy and data protection preferences, policies or local regulations.

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 Correspondent Banking Due Diligence Questionnaire (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.

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.

• PSPs have free choice over which FXP they use (subject to the requirement that the PSP has completed the initial KYC and onboarding process with that FXP - see Onboarding PSPs)

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

This section describes how a payment is processed through Nexus, at a detailed functional level, following a successful Payment Setup process.

The detailed flows below are split into the two separate stages in the Source Country and then in the Destination Country. They also show both the 4-step and 5-step processes that apply to domestic payments.

Minimum liquidity requirements per IPS

FX Providers are responsible for managing their liquidity in various IPSs to ensure that payments from their Destination SAP (or from their own Destination IPS account if they are a member) can always be made.

• Nexus informs FXPs whenever a payment is successfully processed against their quote. (See Notifying FXPs of completed payments.)

• It is the FXP's responsibility to ensure it manages its liquidity so that it is always able to process payments.

• Nexus assumes that FXPs who have active rates hold sufficient funds to honour payments in either direction.

An FXP may be penalised if payments against their quotes fail because of a lack of liquidity in their account at an SAP (or their IPS settlement account, if they are a member of the IPS). (A Destination SAP is likely to check the balance of the FXP’s account before approving or reject payments that reference the FXP’s quote.)

Providing rates and managing liquidity when FX markets are closed

IPSs allow payments to be made 24 hours per day, seven days per week. In contrast, FX markets, where financial institutions buy and sell currencies from each other, are only open during business hours from Monday-Friday. Because of the global nature of FX markets, it is usually possible to trade major currencies for 24 hours a day from Monday morning in Sydney to Friday afternoon in New York, but not over the weekend. This means that there is no “live” market to define FX rates on Saturday and Sunday.

To enable Nexus payments at weekends, FX Providers should continue to provide FX over the weekend. There are two ways they could do this:

• An FXP may update their rates when the FX markets close on Friday, and leave those rates fixed throughout the weekend, since the market rates will not change. In this case, they would “price in” the risk that the rates in the wider FX market on Monday morning may jump relative to the rates when the market closed on Friday evening. This means that the rates charged over the weekend are likely to be less competitive than those during the week, to cover this risk.

• Alternatively, the FXP could continue to update its rates through the weekend. Although the market rates would not change, an FXP may wish to do this to manage their liquidity in the different currencies. For example, they may make their rates better or worse, compared to other FX Providers, in order to attract more or less of certain currencies.

Each FXP must also ensure they have the liquidity to meet expected payment flows over the weekend. This may require active or automated management of the level of funding in their accounts. The FXP could also actively or automatically alter the rates they offer to alter the flow of payments that the FXP is selected for; this will have an impact on how their holdings of each currency increase or decrease. This is a matter for each FXP to manage individually.

Providing rates and managing liquidity outside the FXP’s business hours

Even though FX markets are open 24 hours per day Monday-Friday, not all FX Providers will be global firms that can operate 24 hours per day. Nexus expects FXPs to operate 24/7, meaning that the FXP should develop a strategy for managing their rates and liquidity outside of their core business hours.

Exceptions may be made to the 24/7 requirement for FXPs who are smaller institutions without the capacity to operate outside of their business hours. These exceptions may be time limited with the expectation that the FXP will eventually build the necessary capacity to provide FX to Nexus on a 24/7 basis.

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

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)