BIS Innovation Hub
Nexus - Short ReportAbout the BIS Innovation Hub
  • Introduction
    • Nexus Overview
    • How to use this site
    • Overview Report
    • Terminology
  • Payment Setup
    • Key Points
    • Scope of Nexus payments
    • Steps 1-2: Country, Currency & Amount
    • Steps 3-6: Exchange Rates
    • Steps 7-9: Addressing, Proxy Resolution & Confirmation of Payee
    • Steps 10-11: Sanctions screening
    • Step 12: Ask the Sender for approval
    • Step 13-16: Set up and send the payment instruction
    • Step 17: Accept the confirmation and notify Sender
  • Addressing & Proxy Resolution
    • Key Points
    • Overview of Payment Addressing in Nexus
      • Addressing via Proxies (Aliases)
      • Addressing via Account Details
    • Address Types & Inputs
      • Address Types
      • Address Inputs
      • Financial Institution Identification
      • List of PSPs
      • Examples
    • Proxy & Account Resolution Process
      • Step 1: Sender inputs proxy or account details
      • Step 2: Proxy Resolution Messaging Sequence
      • Step 3: Account Resolution Messaging Sequence
      • Step 4: Source PSP processes the results
      • Masking of Display Names
    • Role of the Proxy Directory Operator (PDO)
      • Obligations on the Proxy Directory Operator
      • Obligations of PSPs using the Proxy Directory
      • Onboarding a Proxy Directory Operator onto Nexus
  • FX Provision
    • Key Points
    • Role of the FX Provider
    • How Third-Party FX provision works in Nexus
    • Joining Nexus as a third-party FXP
    • Accessing Instant Payment Systems
    • Onboarding PSPs
    • Obligations & Compliance
    • Revenue model for FXPs
    • Rates from Third-Party FX Providers
      • Improving rates for larger transactions
      • Improving rates for specific PSPs
    • Quotes
    • Managing Liquidity
  • Payment Processing
    • Key Points
    • Accounts & Relationships
    • Maximum value of a Nexus payment
    • Payment Flow (Happy Path)
      • Detailed Flow in Source Country (Sending)
      • Detailed Flow in Destination Country (Receiving)
      • Booking flow for Source PSPs
      • Notifying FXPs of completed payments
    • Validations, Duplicates & Fraud
    • Time critical vs non-time critical payments
    • Special Scenarios
    • Payment setup for PSPs who provide their own FX
    • Unsuccessful Payments (Exceptions)
      • Rejects
      • Recall Requests
      • Returns
      • Investigation & Enquiry
      • Disputes
      • Reconciliation reports
    • Fees
    • Role and responsibilities of the Instant Payment System Operator (IPSO)
    • Ensuring settlement certainty
    • Annex: 4-step vs 5-step Processes in Domestic Clearing and Settlement
    • Annex: Sponsoring PSPs and Sponsored Entities
  • Settlement Access Provision
    • Key Points
    • Role of the Settlement Access Provider (SAP)
    • Joining Nexus as an SAP
    • SAP onboarding of FXPs (or foreign PSPs)
    • Costs and Revenue for SAPs
    • Obligations on the SAP
    • Processing payments as an SAP
      • Payment Process for the Source SAP
      • Payment Process for the Destination SAP
      • How the Destination IPS initiates the payment via the Destination SAP
    • Managing Liquidity as an SAP
  • Messaging & Translation
    • Key Points
    • General Usage of ISO 20022
      • Adherence to CPMI Harmonised ISO 20022 Data Requirements
    • Compatibility with Instant Payments Plus (IP+)
    • Message transformation by Nexus
    • Specific Message Elements
    • Purpose Codes
    • Message Guidelines (Excel)
    • MESSAGE acmt.023 Identification Verification Request
    • MESSAGE acmt.024 Identification Verification Report
    • MESSAGE: pacs.008 FI to FI Customer Credit Transfer
      • pacs.008 Differences from CPMI Harmonisation Requirements
    • MESSAGE pacs.002 Payment Status Report
      • pacs.002 Differences from CPMI/CBPR+ Guidelines
    • MESSAGE: pacs.004 Payment Return (Not yet supported)
    • MESSAGE: camt.054 Bank to Customer Debit Credit Notification
    • Translation To/From Domestic Message Formats
    • Translating To/From ISO 20022 Codes
  • APIs
    • Overview
    • Countries
    • Currencies
    • Address Types and Inputs
    • Financial Institutions
    • Fees and Amounts
    • Intermediary Agents (SAPs)
    • Quotes
    • ISO 20022 Messages
  • About
    • Contact the Nexus Team
  • LEGAL
    • Terms and Conditions of Use
    • Privacy Notice
    • Cookies Notice
Powered by GitBook
On this page
  • Addressing via IBAN
  • Addressing via Account Identification and Financial Institution Identification
  • Identifying the Account
  • Identifying the Financial Institution
Export as PDF
  1. Addressing & Proxy Resolution
  2. Overview of Payment Addressing in Nexus

Addressing via Account Details

PreviousAddressing via Proxies (Aliases)NextAddress Types & Inputs

Last updated 10 months ago

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

IBANs are not accepted in India, Indonesia, Malaysia, the Philippines, Singapore and Thailand.

Explainer: What is an International Bank Account Number?

An IBAN is a single string of text that includes all the information needed to identify a target account. It is defined by the standard.

  • An IBAN can be up to 34 characters long

  • The first two letters define the country (eg US, GB, FR, DE)

  • The second two letters are check digits (a protection against typos)

  • The remaining digits define a “Basic Bank Account Number” which includes the Financial Institution Identification and an Account Identification.

An IBAN is a fixed length within a specific country, but can vary in length from country to country.

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.

Explainer: Business Identifier Codes (BIC)

A BIC defines a financial institution but not a specific account. Therefore they must always be used in conjunction with an Account Identification.

  • A BIC can be either 8 or 11 digits (eg DBSSSGSG or DBSSSGSGXXX)

  • The 8-digit BIC (BIC-8) defines the country and financial institution

    • The first 4 characters define the “business party”

    • The next 2 characters are the alpha-2 country code (eg US, GB, SG, HK, ID, MY, PH, TH)

    • The final 2 characters are the “business party suffix”. In some cases, one of these digits identifies whether or not the financial institution is a member of the Swift network.

  • The BIC-11 includes the BIC-8 plus an additional 3 digits that define a specific branch of the financial institution

Explainer: Clearing System Member Identification

Each PSP is a member of an instant payment system, or “clearing system” in ISO 20022 terminology. The IPS will assign each member a unique ID. Clearing System Member Identifications are commonly known by local names, such as “routing number”, “sort code”, “bank-state-branch code” etc. Some examples of non-BIC Clearing System Member IDs are given below:

  • Australia: Bank-State-Branch (BSB) code, 6 digits (numeric)

  • India: Indian Financial System Code (IFSC), 11 characters (alphanumeric)

  • Singapore: BIC, 8 characters (alphanumeric)

  • United Kingdom: Sort code, 6 digits (numeric)

  • USA: Routing number, 9 digits (numeric)

Warning: Locally-generated, non-registered BICs

Some IPSs issue non-bank PSPs with an identifier that follows the formatting of BIC but is not registered with Swift (the registration authority). This means that the locally-generated “pseudoBICs” are not included in the Swift database that some PSPs use to validate BICs before sending payments. Consequently, some PSPs may not be able to make payments to PSPs with non-registered pseudoBICs.

It is better to register these locally generated codes with Swift, so that they always validate correctly.

BICs are defined by the standard and are issued by SWIFT. They are often referred to as a SWIFT Code, but are not restricted to SWIFT members or restricted to use on the SWIFT network.

ISO 13616
ISO 9362