# Nexus Overview ## Enabling instant cross-border payments Nexus Global Payments (NGP) is a multilateral payment scheme dedicated to transforming cross-border transactions in line with the G20 Roadmap for Enhancing Cross-border Payments targets of speed, cost, accessibility, and transparency. 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** of the [latest (2024) Nexus report](https://www.nexusglobalpayments.org/wp-content/uploads/2025/03/Project-Nexus-Report-Phase-3.pdf) for an overview of the scheme & governance, business model and technology architecture of Nexus. This site contains detailed **technical documentation,** covering: * [ISO 20022 message specifications](/messaging-and-translation/message-guidelines-excel) for Nexus * [API specifications](/apis/overview) {% hint style="warning" %} Nexus is not yet operational, and the information on this site will be updated as the design of Nexus is refined and improved. {% endhint %} Over 100 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](https://www.nexusglobalpayments.org/contact-us/) to enhance the blueprint. ### Next steps for Nexus Originally conceptualised and developed by the Bank for International Settlements (BIS) in collaboration with central banking partners, Nexus standardises the way instant payment systems (IPS) connect across countries. To bring this vision to life, Nexus Global Payments (NGP) was established on March 26, 2025 by the central banks and IPS operators of India, Malaysia, the Philippines, Singapore, and Thailand. These pioneering jurisdictions form the inaugural cohort of Nexus owners provided the foundational capital to build and scale the platform. As we grow, we aim to welcome additional participants and owners, fostering a truly global and interoperable payment network.
 NGP is a not-for-profit organisation incorporated in Singapore, which is dedicated to managing the Nexus scheme and advancing the mission: to enable fast , efficient, and safe cross-border payments at scale. With NGP at the helm, Nexus has transitioned from a BIS-led initiative to an independent and collaborative effort, to shape the future of global payments. {% hint style="info" %} ### Read the latest (July 2024) Report This [**overview report**](https://www.nexusglobalpayments.org/wp-content/uploads/2025/03/Project-Nexus-Report-Phase-3.pdf) explains the benefits of linking IPS to provide cross-border payments and how Nexus could accelerate the growth of instant cross-border payments. It describes the scheme & governance, business model and technology architecture for Nexus. It builds on a year-long collaboration with 5 central banks and their payment system operators. {% endhint %} (Use of this website and the Nexus materials is subject to the [terms and conditions](/legal/copyright-terms).) # How to use this site We recommend starting by reading **chapter 2 of the** [**2024 overview report**](https://www.nexusglobalpayments.org/wp-content/uploads/2025/03/Project-Nexus-Report-Phase-3.pdf) 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](/payment-setup/key-points) 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](/addressing-and-proxy-resolution/key-points) 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](/fx-provision/key-points) describes the role of financial institutions who swap the sender's currency for the recipient's. * [Payment Processing](/payment-processing/key-points) 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](/settlement-access-provision/key-points) 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](/messaging-and-translation/key-points) 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. {% hint style="info" %} This site is a live document, and will be regularly updated with the latest specifications as the project advances. We welcome [feedback and suggestions](broken://pages/GLzX6ut1z1esZXAGDgNH) for improvement to the design of Nexus. {% endhint %} # Terminology {% hint style="success" %} ### Use of Must / Should / Can / May These implementation guides use the following terminology to indicate the importance of functionality or a recommendation: * **Must (not)**: Mandatory to include/do * **Should (not)**: Best practice to do/include and highly recommended to do/include to avoid extra work/impact. Only ignore if this clashes with local practices/law * **Can/Could (not)**: Suggestion which could improve the user experiences, lower (implementation running) costs/effort and/or reduce risk, but these results can be achieved/solved in other ways. Not mandatory to incorporate. * **May (not) / Is (not) allowed to**: This is functionality or a choice left up to the IPSO, PSP, SAP or FX Provider {% endhint %} ## Nexus-specific terminology {% hint style="info" %} This guide refers to a number of actors in Nexus: *Payment Service Providers (PSPs), Instant Payment System Operators (IPSOs), Foreign Exchange Providers (FXPs) and Settlement Access Providers (SAPs).* For a primer on each of these actors please see [Chapter 2.3 of the Nexus (2024) report](https://www.nexusglobalpayments.org/wp-content/uploads/2025/03/Project-Nexus-Report-Phase-3.pdf). {% endhint %} ## 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.
Guideline to ISO 20022 notation The following notation is used when referring to **ISO 20022 elements**: * For readability, the path to an element is written with unabbreviated element names, with the symbol > separating each element. Users should refer to the official usage guidelines for the equivalent abbreviated path. * The top-level \ element is not listed * The top-level message wrapper (eg `FI to FI Customer Credit Transfer`) is omitted if the message in question is obvious from the content on the page * Three dots are used to show that the higher levels of a message structure have been omitted. For example, for pacs.008: * *Credit Transfer Transaction Information > Payment Identification > UETR* * *… > Debtor Account > Identification > IBAN*
## 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](/fx-provision/quotes) for further explanation. # Change Log **Last update: 24/08/2026** This change log records all notable updates to this documentation. It is intended to provide transparency on what has changed, when it changed, and why the change was made. Entries are listed in reverse chronological order, with the most recent changes first. Each entry highlights additions, modifications, clarifications, and removals that may be relevant to readers, implementers, or operators. Minor editorial changes that do not affect meaning or requirements may be grouped or omitted. The change log should be used alongside versioned documents and release communications to understand the evolution of the content over time. | Change Date | Chapter/Topic | Change Type | Description | | ----------- | -------------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 24/08/2026 | API | Added | Added 2 FXP specific APIs | | 24/08/2026 | API | Added | Added specific API for each ISO20022 message with examples | | 24/08/2026 | API | Updated | Updated OpenAPI Spec with descriptions | | 18/08/2026 | Payment Setup - Step 15 | Updated | Added PNDG as a status in pacs.002 | | 18/08/2026 | Payment Processing - Value Limit | Clarified | Clarified that Nexus only applies value limits on individual payments. | | 18/08/2026 | Message Specs | Updated | Updated message specs. See the Excel for the detailed Change Log. | | 07/07/2026 | Quotes | Updated | Updated the quote validity in line with the Nexus Scheme Rulebook. Quotes have an expiry time of 600 seconds. | | 07/07/2026 | Agreed Rate | Updated | Updated the use of Agreed Rate instead of Exchange Rate in line with the 2025 version of the ISO200222 XML messages. Removed the use of Quote ID in the Additional Remittance Information section. | | 07/07/2026 | Fees | Updated | Updated the Destination PSP fee to be defined on Country level instead of a generic Nexus fee. | | 07/07/2026 | Payment Flow | Updated |

Updated the payment flows in line with the Nexus Scheme Rulebook. This includes additional clarification on the exception and investigation flows.
Added the optional registration of an IPSO defined minimum transaction amount.

| | 07/07/2026 | Message Guidelines | Updated | The Message Guidelines are updated to the latest 2025 version and split between sending and receiving side. Additional updates are declared in the message guidelines document. | | 07/07/2026 | Additional optional APIs | Added | Added descriptions of additional optional APIs. | # Key Points {% hint style="info" %} This section describes how the **Source PSP should set up and send a Nexus payment**, using the Nexus APIs. \ A simpler, non-technical walkthrough of the user journey for the Sender is given in the [Nexus report (page 22)](https://www.nexusglobalpayments.org/wp-content/uploads/2025/03/Project-Nexus-Report-Phase-3.pdf). Further information on each step is given in the corresponding sections in the left-hand menu: * [Addressing and Proxy Resolution](/addressing-and-proxy-resolution/key-points) * [FX Provision](/fx-provision/key-points) * [Payment Processing](/payment-processing/key-points) * [Settlement Access Provision](/settlement-access-provision/key-points) * [Messaging & Translation](/messaging-and-translation/key-points) {% endhint %} # Scope of Nexus payments 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. {% hint style="warning" %} This guide does not yet cover payments that are initiated by scanning a QR code, including: * proxy payments, where the proxy is embedded in a QR code * “merchant payments”, eg payments from a customer to a retailer or other business, using dynamic QR codes at the point of sale (either physical or e-commerce). These features will be added to Nexus in due course. {% endhint %} 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. {% hint style="info" %} **Nexus does not accept bulk/batch payment instructions.** However, it is acceptable for a PSP to receive a bulk/batch payment file from its customers (or for an IPS to receive a bulk/batch payment file from its PSPs), “debulk” the file and submit the payments one-by-one as individual payments through Nexus. The Nexus Scheme Rulebook requirements will apply for these payments in full including requirements regarding transparency of fees, timelines and compliance checks. It will be the responsibility of the Source PSP (or IPS) to correlate the individual transactions (and their responses) back to the original batch/bulk file, if required. {% endhint %} ***“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 combines two *domestic* instant payments into a cross-border instant payment. **“Cross-Border, Cross-Currency”**\ Nexus is designed for instant payments requiring a currency conversion, using an FX Provider. See [FX Provision](/fx-provision/key-points). {% hint style="danger" %} Nexus does not currently support payments to and from the same currency (even if they are in different countries) {% endhint %} # Steps 1-2: Country, Currency & Amount {% hint style="info" %} The rest of this section assumes that readers are familiar with the main actors in Nexus: Payment Service Providers (PSPs), Instant Payment System Operators (IPSOs), Foreign Exchange Providers (FXPs) and Settlement Access Providers (SAPs). For a primer on each of these actors please see [Chapter 2.3 of the Nexus (2024) report](https://www.nexusglobalpayments.org/wp-content/uploads/2025/03/Project-Nexus-Report-Phase-3.pdf). {% endhint %} 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. {% hint style="warning" %} Note that there is no "Nexus app" and payment Senders do not register with or interact directly with Nexus. The app shown is a mockup designed to give an example of how a PSP may integrate the service into their own app. {% endhint %} ### 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, as well as the expected time it will take to process the transaction, the maximum amount that can be transferred and any specific mandatory fields required for this country. If the Sender selects a country with more than one currency, the PSP should immediately: 1. Display a second form element (eg `` 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. # Address Types 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 [ISO 20022 External Code Set](https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets) The table below lists the possible address type codes in Nexus. The most commonly accepted address types are bolded. {% hint style="info" %} Even IPS that use ISO 20022 domestically often use proprietary codes to describe proxies, for example, using "MSISDN" rather than the ISO 20022 "MBNO". There are particular translation challenges to consider around the use of proxy code - please see [Translating To/From ISO 20022 Codes](/messaging-and-translation/translating-to-from-iso-20022-codes) for further detail. {% endhint %} ### Table: Address types & codes
CODE (ISO 20022)MEANINGTYPENOTES
IBANInternational Bank Account NumberAccount IdentificationTypically defines country, PSP and account. (In some countries, the BIC or Clearing System Member Id is not included in the IBAN, so separate enrichment tables must be used to map a subset of the IBAN to the relevant FI Id.)
ACCTAccount Identification (to be used in conjunction with a Financial Institution Identification)Account IdentificationMust be used in conjunction with a Financial Institution Identification (see table below)
BIIDBiller Subscriber IdentificationProxy Id
CINCCertificate of Incorporation NumberProxy IdCompany registration number
COTXCorporate Tax IdentificationProxy Id
COIDCountry Authority IdentificationProxy Id
CUSTCustomer identification NumberProxy Id
DNAMDomain Name (Internet)Proxy Id
DRLCDriver License NumberProxy Id
EIDNElectronic IdentificationProxy Id
EMALEmail addressProxy Id
EWALE-Wallet identificationProxy Id
PVTXIndividual tax identificationProxy Id
LEICLegal Entity Identifier CodeProxy Id
MBNOMobile phone numberProxy IdMost commonly accepted proxy type
NIDNNational identification numberProxy Id
CCPTPassport numberProxy Id
SHIDScheme identification NumberProxy IdOften used for virtual payment addresses
SOSESocial Security NumberProxy Id
TELETelephone Number (land line)Proxy Id
UBILUtilities Subscription IdentificationProxy Id
VIPNVehicle Identification Plate NumberProxy Id
TOKNVirtual payment addresses (treated as a “token”)Proxy Id
# 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) {% hint style="warning" %} In some cases, such as the Philippines, a Financial Institution Identification must also be provided for each proxy (as the same proxy may be registered to multiple financial institutions in the Philippines). This will indicated in the GET countries API. {% endhint %} 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 | ELEMENT | SUB ELEMENT | FORMAT | USAGE | | -------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Label | Code | Text |

Same as the Address Type code or Financial Institution Identification Type code above. E.g. MNBO, ACCT, IBAN

This code can be mapped to the app user’s language.

| | | Title | Map, where key is the 2-letter language code (eg “en”) and the value is the explanatory title |

Further description that can be used to guide the Sender, to be used in a tooltip or explanatory text below the input form.

A description in English (“en”) should always be provided. PDOs may choose to add additional languages based on the likely language of Senders to that country. (For example, countries may wish to add the languages of their closest trading partners and remittance corridors.)


For example, for a proxy type NIDN (National Identify Number) for Singapore, the description may be “NRIC/FIN” – two national identity number types)

| | Attributes | Name | ENUM: accountIdOrProxyId, addressTypeCode, finInstId |

Suggested name of the form element that takes the input from the Sender. (Note: addressTypeCode would be a hidden input that is not visible to the Sender.)

Note: this is NOT the name of the input type that should be shown to the Sender – for that, see Label.Code

| | | Type | Valid HTML input “type” attribute | Describes the type of HTML input element, eg text, tel, number, email | | | Pattern | Regular expression | Used to validate the form. (For email, this should be null, relying on the browser or app’s default email validation instead.) | | | Placeholder | Text | An example value that can optionally be shown in the input element before the Sender begins to enter information | | | Required | true/false | Whether this input is required or optional. (Currently all inputs are set to required. Optional inputs may be used in cases where a comparison model of account resolution is used, in which the Sender can optionally provide information about the Recipient that would be compared by the Destination PSP against their own verified records.) | | ISO 20022 Path | (Code of the message type without the dot e.g. “*acmt024”)* | Text |

The XPath to the position in an ISO 20022 message where this information can be used. Multiple message types may be specified, depending on whether proxy resolution is required first, or whether the input can be used directly in the pacs.008 payment instruction.

NB: The message name is defined without the period/dot character “.”, because the dot character is used in JavaScript to refer to properties of a JSON object (eg “attributes.name”).

| # Financial Institution Identification ## 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. {% hint style="info" %} When the address type is ACCT, the response from the `Address Inputs` API will automatically include a field for the Financial Institution Identification. {% endhint %} ### Using with a Proxy {% hint style="info" %} In some countries, such as the Philippines, the same proxy can be registered to multiple financial institutions. Therefore, it is necessary to collect the Financial Institution Identification for the Recipient. {% endhint %} ### TABLE: Financial Institution Identification Types The following Financial Institution Identification types are defined in ISO 20022. | **CODE (ISO 20022)** | **MEANING** | **TYPE** | **NOTES** | | -------------------- | -------------------------------------------------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | BICFI | Business Identifier Code for Financial Institution | Financial Institution Id | Used in conjunction with an Account Identifier (and in some countries, with the proxy) | | LEI | Legal Entity Identifier | Financial Institution Id | We are not aware of any IPS that uses LEIs to address payments, but the ISO 20022 messages can support use of LEI. | | ClrSysMmbId | (Non-BIC) Clearing System Member Id | Financial Institution Id | Used in conjunction with an Account Identifier. Maps to ISO 20022 element *Financial Institution Identification > Clearing System Member Identification > Member Id* | # List of PSPs 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 **`