# 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). {% 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”).

| ### --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.nexusglobalpayments.org/addressing-and-proxy-resolution/address-types-and-inputs/address-inputs.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.