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.
