The Source PSP will now receive an acmt.024 response message from Nexus.
The Source PSP will check the acmt.024 to see if the proxy or account resolution has been successful.
If the proxy or account resolution has failed, the Source PSP will display the reason to the Sender, based on the Reason Code provided. (For example: “This proxy is not associated with any account.”)
If the proxy resolution is successful, the Source PSP must:
Check if the display name is provided in the acmt.024 response message (in the Account > Name element):
If a display name is provide, the Source PSP should the display name to the Sender and ask them to confirm that this is the name they’re expecting to see (see Step 9 of the User Journey).
If no display name is provided, the app should show the Sender a warning to the effect of “We were unable to check the name of the account holder. Please double-check the account details are correct before sending the payment.” The Sender may proceed with the payment at their own discretion.
If no real name was provided in Party > Name, the Source PSP does not have sufficient information about the Recipient to complete the necessary compliance and sanctions screening checks.
In this case, the Source PSP must ask the Sender to provide this information. (This is the least preferred outcome as it relies on potentially inaccurate information from the Sender, rather than verified information from the Destination PSP or Proxy Directory.)
Note: The process below is shown with demonstration screens in Sending Payments > Steps 7-9 Addressing, Proxy and Confirmation of Payee.
When the Sender selects the Destination Country for a payment in their PSP’s app, the Source PSP will call the GET /countries/{countrycode}/addressTypes API operation, specifying the country code. Nexus will respond with a full list of address types for that country, including any proxy types, Account Identification formats and/or IBAN. (See Address Types for details.)
The Source PSP will show the Sender a form allowing them to select one of the possible address types, according to the details they were given by the Recipient.
The Sender selects an address type (eg the “Mobile” option on the form; in the case of a payment to Singapore, this would select the address type with the ID “SGMBNO”).
The Source PSP will call the GET /addressTypes/{addressTypeId}/inputs API operation to retrieve the input fields that are required for this address type.
The Source PSP could retrieve the address inputs for all address types in a single API call by using
GET /countries/{countryCode}/addressTypesAndInputs/
instead of
GET /countries/{countryCode}/addressTypes/
The Source PSP’s app will use the address inputs to generate the app form to enter the address details
The Sender will enter the details that they were given by the Recipient (eg “+6580001234”).
The Source PSP’s app must validate that the address details entered by the Sender are in the correct format. These validation rules will be provided as regular expressions (regex) in the address inputs information provided by Nexus. This allows the PSP to validate the format of the data in-app, prior to any communication with Nexus or the proxy scheme.
As per normal practice, the Recipient’s full name must be shared in full (unmasked) with the Source PSP to support sanctions screening.
This information should be provided by the Proxy Directory or Destination PSP in the IdVrfctnReq/Rpt/UpdtdPtyAndAcctId/Pty/Nm element of the acmt.024 message. See
The Proxy Directory or Destination PSP may also share a ‘display name’, which could be the full name (unmasked) or the full name partially masked.
This should be provided in the IdVrfctnReq/Rpt/UpdtdPtyAndAcctId/Acct/Nm element of the acmt.024 message.
The Proxy Directory or Destination PSP is responsible for masking the name according to their own privacy and data protection preferences, policies or local regulations.
Nexus will not mask or alter the information provided in the IdVrfctnReq/Rpt/UpdtdPtyAndAcctId/Acct/Nm element of the acmt.024 message.
Following on from , assuming the Sender entered a proxy, the Source PSP will send Nexus an ISO 20022 message that includes the proxy details.
Nexus will:
look for the Country Code in the Assignee > Agent > PostalAddress > Country element
identify the relevant proxy directory in that country, and
update the Assignee to the BIC of the proxy directory (or its parent IPS Operator). This is the only change that is made to the message.
Nexus will send the proxy resolution request to the Destination Proxy Directory Operator.
The Destination Proxy Directory should first check if the proxy is associated with an account.
If the proxy successfully maps to an account, the proxy directory should prepare and return an acmt.024 response message that contains, at a minimum:
Account details, in the form of either:
an IBAN, OR
the Financial Institution Identification (eg BIC) AND the Account Identification of the linked account
the real name associated with the account (wherever possible) – this will be used by the Source PSP when sanctions screening the Recipient.
This should be stored in the element UpdatedPartyAndAccountIdentification > Party > Name.
Note that wherever possible, the full real name should be returned, as this information supports accurate and automated sanctions screening.
a display name that can be shown to the Sender to allow them to confirm that the account holder is the intended Recipient. This could be the full name (where privacy and data protection rules allow this to be shown to the Sender) or a partially obscured name, depending on the proxy service.
This value should be in the element UpdatedPartyAndAccountIdentification > Account > Name
Note: this is a non-standard use of the Account > Name element, which should normally describe the name of the account rather than the name of the account holder. Unfortunately, the acmt.024 message structure does not currently have a dedicated element for a display name that can be shown to the Sender but which may be different from the real account holder name.
The proxy directory should send this response back to the Nexus.
The message will be formatted as an ISO 20022 acmt.023 message. The PDO must be able to accept the message in this format. If the domestic proxy resolution message format is different, the IPSO is responsible for translating the message from the Nexus acmt.023 to the domestic format message before processing the proxy resolution request (See for further details.)
If there is no associated account, the proxy directory should respond with an acmt.024 response including the appropriate error code in the Report > Verification > Reason > Code element. (See for further information.)
See below for details on how Nexus will handle this response.
Nexus uses the ISO 20022 messages acmt.023 and acmt.024 for all communication related to proxy resolution or account resolution.
The remainder of this guide assumes that the IPS operator, proxy directory and member PSPs can support the acmt.023 & acmt.024 messages according to the Nexus usage guidelines. However, this is not the case in many countries.
IPSOs that do not currently support acmt.023 andacmt.024 must either:
translate these messages to the relevant domestic format, or
adapt their systems (including the proxy directory, and the systems of their member PSPs) to support these messages.
These options and the translation process are described in Messaging & Translation.
The diagram below shows the proxy and account resolution process at a high level.
(The user experience in the app is shown in more detail (with visual examples) in Payment Setup).
A Sender can enter either the Recipient’s proxy ID or account ID into their PSP’s app
The Source PSP will send this information to Nexus
If the Sender provided a proxy, Nexus will connect to the relevant proxy directory and request the corresponding account details
The proxy directory will return the corresponding account details.
If either (a) the Sender provided an account ID, or (b) the proxy resolution response from the Proxy Directory includes the account ID, Nexus will:
Check if the Destination PSP is able to accept account resolution requests.
If so, Nexus will send an account resolution request to the Destination PSP
Nexus will combine the information from the proxy directory and the Destination PSP (if an account resolution request was sent), and send this back to the Source PSP
The Source PSP will check the information in the response:
If a Display Name was provided, the Source PSP will ask the Sender to confirm that the payee is who they expect
If no Display Name is provided, the Sender will be advised to proceed with the payment at their own risk
If no other information is provided (such as the full name on the account), then the Source PSP will need to ask the Sender to provide this information so that the Source PSP can perform compliance and sanctions screening checks on the Recipient.
The rest of this section covers those steps in more detail.
At this step, Nexus has access to account details for the Recipient, from one of two sources:
An acmt.023 message from the Source PSP, which includes the Account Identification and Financial Institution Identification provided by the Sender, OR
An acmt.024 response from the Destination Proxy Directory, which includes the account details associated with the proxy provided by the Sender.
If the Destination PSP is enabled to process acmt.023 requests, Nexus will send an updated acmt.023 to the Destination PSP to get verified information about the Recipient directly from the Destination PSP, as follows.
Supporting account resolution is optional for each PSP, and Nexus would be aware of which PSPs are willing and able to support account resolution requests. Nexus would not send account resolution requests to PSPs that are unable to process them.
Nexus will:
look for the Agent Id in the Agent > FinancialInstitutionId element
check whether that Agent is reachable through Nexus
If not, Nexus will prepare an actm.024 with the Report > Verification element set to “false” (since it is not possible to proceed with the payment) and the appropriate Reason code (AGNT, Incorrect Agent – see #toc143525641).
check whether the Agent is able to process account resolution requests. (Not all PSPs will be able to; this information will be recorded by Nexus when a new PSP is onboarded.)
If the Destination PSP can accept account resolution requests, Nexus will:
update the Assignee for the message to the Destination PSP
forward the acmt.023 request message to the Destination PSP (via the IPS that is connected to that Agent).
If the Destination PSP cannot accept account resolution requests:
If the Sender originally provided a proxy, Nexus will forward the acmt.024 that was received from the Destination Proxy Directory in Step 2
If the Sender originally provided account details, Nexus will prepare an acmt.024 with the Report > Verification element set to “false” (since account resolution was not possible) and the appropriate Reason code (proposed to be AB08 – Offline Creditor Agent).
The Destination PSP should use the account ID provided to look up the corresponding account.
If the account does not exist or is inactive, they should return an acmt.024 with the Report > Verification element set to “false” and the appropriate Reason code (such as AC01, AC04, AC06 – see #toc143525641).
If the account is active, they should prepare an acmt.024 response and add (to the UpdatedPartyAndAccountIdentification block) the following information:
the real name associated with the account (wherever possible) – this will be used by the Source PSP when sanctions screening the Recipient.
This should be in the element UpdatedPartyAndAccountIdentification > Party > Name
a display name that can be shown to the Sender to allow them to confirm the account holder is the intended Recipient.
This could be the full name (where privacy and data protection rules allow this to be shown to the Sender) or a partially obscured name, depending on the proxy service.
The Destination PSP is responsible for masking the name.
This value should be in the element UpdatedPartyAndAccountIdentification > Account > Name
Note: this is a non-standard use of Account > Name, which should normally describe the name of the account rather than the account holder. Unfortunately, the acmt.024 does not currently have a dedicated element for a display name that can be shown to the Sender but which may be different from the real account holder name.
In addition, if the Destination PSP can supply some or all of the following information will support more efficient sanctions screening, with fewer false positive alerts:
Address
Date and Place of Birth
The Destination PSP should now prepare an acmt.024 response and send it to Nexus. The flow diagram below explains how the Destination PSP should prepare the message.
Nexus will forward the acmt.024 response (from the Destination PSP) to the Source PSP, via the IPS. See Step 4.
In some jurisdictions, PSPs will be unwilling to share any information about the Recipient/Creditor before a payment is initiated. In this case, an alternative form of verification (often used in Europe) is to ask the Sender to provide information about the Recipient, and then ask the Destination PSP to confirm whether or not that information is accurate. This "comparison" or "matching" process will be developed for Nexus in a future phase of development.
