# Step 3: Account Resolution Messaging Sequence

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.

{% hint style="info" %}
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.
{% endhint %}

<figure><img src="https://260996932-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdlTzGEXDmi664xppppmm%2Fuploads%2Fgit-blob-cfe36dbfd5b7a4472bace03c9dfd4a2e498dc74e%2Fimage%20(19).png?alt=media" alt=""><figcaption><p>Account resolution flow diagram<br>(click to expand)</p></figcaption></figure>

### **1. Nexus**

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](https://docs.nexusglobalpayments.org/messaging-and-translation/message-acmt.024-identification-verification-report#toc143525641 "mention")).
* 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](https://docs.nexusglobalpayments.org/addressing-and-proxy-resolution/proxy-and-account-resolution-process/step-2-proxy-resolution-messaging-sequence)
  * 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*).

### **2. Destination PSP**

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](https://docs.nexusglobalpayments.org/messaging-and-translation/message-acmt.024-identification-verification-report#toc143525641 "mention")).
* 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`*

{% hint style="warning" %}
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.
{% endhint %}

{% hint style="info" %}
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
  {% endhint %}

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

<figure><img src="https://260996932-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdlTzGEXDmi664xppppmm%2Fuploads%2Fgit-blob-d990b576598ade0e8c6684b5c2fae45c2c6e1561%2Fimage%20(20).png?alt=media" alt=""><figcaption><p>Flow diagram: preparation of acmt.024 response by the Destination PSP</p></figcaption></figure>

### **3. Nexus -> Source IPS -> Source PSP**

Nexus will forward the `acmt.024` response (from the Destination PSP) to the Source PSP, via the IPS. See [**Step 4**](https://docs.nexusglobalpayments.org/addressing-and-proxy-resolution/proxy-and-account-resolution-process/step-4-source-psp-processes-the-results).

{% hint style="danger" %}
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.
{% endhint %}