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