> For the complete documentation index, see [llms.txt](https://docs.nexusglobalpayments.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexusglobalpayments.org/addressing-and-proxy-resolution/proxy-and-account-resolution-process/step-2-proxy-resolution-messaging-sequence.md).

# Step 2: Proxy Resolution Messaging Sequence

Following on from [Step 1](/addressing-and-proxy-resolution/proxy-and-account-resolution-process/step-1-sender-inputs-proxy-or-account-details.md), assuming the Sender entered a proxy, the Source PSP will send Nexus an ISO 20022 [`acmt.023`](/messaging-and-translation/message-acmt.023-identification-verification-request.md) message that includes the proxy details.

<figure><img src="/files/kIMV7xqKRArFhwkRrX8c" alt=""><figcaption><p>Proxy resolution flow diagram</p></figcaption></figure>

### **1. Nexus (Message Transformation)**

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.

### **2. Nexus -> Destination Proxy Directory**

Nexus will send the proxy resolution request to the Destination Proxy Directory Operator.

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 [Messaging & Translation](/messaging-and-translation/key-points.md) for further details.)

#### **Scenario 1: No associated proxy**

The Destination Proxy Directory should first check if the proxy is associated with an account.

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 [MESSAGE acmt.024 Identification Verification Report](/messaging-and-translation/message-acmt.024-identification-verification-report.md#toc143525641) for further information.)

#### **Scenario 2: Proxy successfully resolved**

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

{% hint style="warning" %}
Note: this is a non-standard use of the *Account > Name* elemen&#x74;*,* 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.
{% endhint %}

The proxy directory should send this response back to the Nexus.

See [**Step 3**](/addressing-and-proxy-resolution/proxy-and-account-resolution-process/step-3-account-resolution-messaging-sequence.md) below for details on how Nexus will handle this response.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nexusglobalpayments.org/addressing-and-proxy-resolution/proxy-and-account-resolution-process/step-2-proxy-resolution-messaging-sequence.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.