Steps 7-9: Addressing, Proxy Resolution & Confirmation of Payee

See Addressing & Proxy Resolution for further detail on how addressing is managed in Nexus.

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.

The address-types-and-inputs API combines the results of two API operations into one response:

• GET /countries/{countryCode}/address-types

• GET /address-types/{addressTypeId}/inputs

A PSP could also choose to call the two APIs above independently to avoid retrieving data for address types that may not be selected by the Sender.

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.

The Sender will select the type of proxy they were given, or local account number or IBAN, and then enter the details.

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.

This process works when a proxy is used to address a payment. In some countries, particularly in Europe, confirmation of payee works differently. First the Sender is asked to provide the expected name of the Recipient, which is compared by the Destination PSP to the actual name they have on file. The Sender is then informed whether the actual name is matches the expected name, or is a close match, or not a match at all. This approach to confirmation of payee will be added to a future version of Nexus.

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.

In some cases, the real name AND display name fields will both be blank. This can occur when:

The Destination PSP does not support the acmt.023/acmt.024 process, AND either:

• The proxy lookup service itself does not store or provide the account holder’s name or nickname OR

• The Sender provided a local account number (so there was no proxy lookup)

In this situation, there is no way for the Sender to confirm the identity of the Recipient and this confirmation-of-payee step can be skipped. In such cases, the Sender must send the payment “blind” to the real identity of the account holder. This may increase the risk of them making a payment to a fraudulent or mistaken account.

This is one reason why it is always preferable to list the proxy options first in the addressing form, rather than IBAN or a local account number; most proxy schemes will return a name or nickname but it is possible that not all PSPs will support the account resolution process.)