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

7.1 App generates the addressing form

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.

Addressing payments using IBAN or local account details

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.

7.2 Sender selects an address type

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.

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

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

WORKED EXAMPLE: Data stored by the app

This JSON gives an example of the data that the PSP's app will need to store whilst the payment is being set up, based on the examples shown. We can now add the proxy details.

// Example payment object stored in PSP's app
"Payment": {
        "DstCtry": "SG", // Destination Country
        "DstCcy": "SGD",  // Destination Currency
        "AmtCcy": "SGD" // the Sender specified the Destination Currency Amount, not Source Currency Amount 
        "Amt": 150, // value of the payment, in AmtCcy
        "Qt": { 
                "QtId": "05201109-1cf1-42ba-b661-32d9f6bc8b63", // Quote Id provided by Nexus
                "AdjSrcAmt": 100, // Nexus calculated this value for the quote
                "AdjDstAmt": 150, // value not capped by Nexus
                "Rate": 1.5000
        },
        "Prxy" {
                "PrxyTp": "MBNO",
                "PrxyVal: "[phone]"
        },
}

Step 8: PSP sends proxy or account details to Nexus

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:

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 PSP identifier (eg BIC) and account number, or return an error if the proxy is not registered.)

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

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

4. Nexus will respond to the PSP with:

   1. the PSP identifier

   2. the account number

   3. a list of the IPSs in which the PSP is reachable

   4. the Recipient’s name or nickname (as provided by the proxy service or the response to the RFI)

   5. any further personal data on the Recipient that Nexus is able to retrieve from the Destination PSP via the RFI.

WORKED EXAMPLE: Data stored by the app

This JSON gives an example of the data that the PSP's app will need to store whilst the payment is being set up, based on the examples shown. We can now add the account and creditor details.

// Example payment object stored in PSP's app
"Payment": {
        "DstCtry": "SG", // Destination Country
        "DstCcy": "SGD",  // Destination Currency
        "AmtCcy": "SGD" // the Sender specified the Destination Currency Amount, not Source Currency Amount 
        "Amt": 150, // value of the payment, in AmtCcy
        "Qt": { 
                "QtId": "05201109-1cf1-42ba-b661-32d9f6bc8b63", // Quote Id provided by Nexus
                "AdjSrcAmt": 100, // Nexus calculated this value for the quote
                "AdjDstAmt": 150, // value not capped by Nexus
                "Rate": 1.5000
        },
        "Prxy" {
                "PrxyTp": "MBNO",
                "PrxyVal: "[phone]"
        },
        "Cdtr": {
                "Nm": "Wei Long",
                "Addr": {} // full address may be provided for sanctions screening
        },
        "CdtrAcct": {
                "Id": { } // account Id in local format or IBAN
        },
        "CdtrAgt": {
                "Id": { } // Destination PSP Id here, likely as a BIC
        }
}

Step 9: Ask Sender to Confirm Payee

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