Next the 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 proxy formats, since these are usually easier for the Sender to input, followed by IBAN, followed by any domestic account formats.
See API - Proxy Service for instructions on generating this form dynamically using the GET /countries/{country_code}/proxyschemes/
. 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.
If the Destination IPS accepts IBAN or local account details, these can also be used through Nexus.
The PSP should check the whether the IBAN is accepted. This is defined in the IPSs/IPS/IBANAccptdInd
element. If IBAN is accepted (IBANAccptdInd = true
), this should be displayed in the addressing options field after the various proxy formats.
The PSP should also check whether a local account format is accepted, alongside a PSP identifier (such as BIC). This is defined in the /IPSs/IPS/LclAcctId/LclAcctIdAccptdInd
element of the response to GET /countries/{country_code}/ipss
. This option should be displayed last.
The PSP should ask the Sender to select either (a) a proxy (eg. phone number) or (b) a PSP identifier (eg BIC) and account details, depending on what information the Recipient has given them.
On the next screen (right pane in the diagram above), the Sender should be asked to enter the specific addressing details, depending on the option they selected before. (See API - Proxy Service for instructions to generate this form dynamically.)
The PSP should now send either the proxy or account details provided by the Sender to the GET /creditors/
API operation. This triggers the following steps:
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 PSP identifier (eg BIC) and account number, or return an error if the proxy is not registered.)
Using the PSP identifier (provided by the proxy lookup service or by the Sender), Nexus will check that the Destination PSP is enabled to receive Nexus payments and able to apply sanctions screening to incoming payments (ie “Nexus reachable”). If not, Nexus will return an error (“Destination PSP not reachable”).
Nexus will check whether the Destination PSP supports the Request For Information process. If so, it will contact the Destination PSP via the RFI
API (or a camt.026 message) to request verified information about the Recipient, such as the name and address, so that the PSP doesn’t need to ask the Sender for this information. (See Request for Information)
Nexus will respond to the PSP with:
the PSP identifier
the account number
a list of the IPSs in which the PSP is reachable
the Recipient’s name or nickname (as provided by the proxy service or the response to the RFI)
any further personal data on the Recipient that Nexus is able to retrieve from the Destination PSP via the RFI.
The PSP should now ask the Sender to confirm that they recognize the Recipient’s name or nickname before proceeding with the payment. The confirmation 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.
In most cases, the response to the Creditors response will include either the Recipient’s real name or a nickname defined by the Recipient. This information is retrieved from either:
the proxy lookup service in the Destination Country, or
the Request for Information sent directly to the Destination PSP
The 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 nickname and real name fields will both be blank. This can occur when:
The Destination PSP does not support RFI, 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 alway 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 many banks will not support the RFI process.)