> 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/messaging-and-translation/message-admi.002-message-reject.md).

# MESSAGE admi.002 Message Reject

**admi.002 (MessageRejectV01)** is the message Nexus and IPSOs use to reject a message for **technical** reasons, after it has already been accepted for processing. 

It tells the sender that the message itself is defective (for example, a required element is missing, a code is invalid or a format is wrong) and cannot be processed. The sender must correct the message and send it again.

#### Two directions

admi.002 is used in both directions between Nexus and IPSOs.

| DIRECTION        | WHEN IT IS SENT                                                    | Spec                                                                                                                                                   |
| ---------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Nexus → IPSO** | Nexus finds a technical problem in a message sent by an IPSO.      | [admi.002 Message Reject (Nexus to IPSO)](/messaging-and-translation/message-admi.002-message-reject/message-admi.002-message-reject-nexus-to-ipso.md) |
| **IPSO → Nexus** | An IPSO finds a technical problem in a message delivered by Nexus. | [admi.002 Message Reject (IPSO to Nexus)](/messaging-and-translation/message-admi.002-message-reject/message-admi.002-message-reject-ipso-to-nexus.md) |

In both cases, the admi.002 goes back to **the party that sent the rejected message**.

#### admi.002, HTTP errors and business rejections

| SITUATION                                                                                                                           | HOW IT IS REPORTED                                                                                     |
| ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| The message fails schema (XSD) validation when it is received                                                                       | HTTP error (e.g. **HTTP 400**). No ISO 20022 message is sent.                                          |
| The message was accepted (**HTTP 202**) but then fails a technical check                                                            | **admi.002**                                                                                           |
| The message is technically valid but the business outcome is negative (e.g. agent not found, duplicate payment, proxy not resolved) | The normal ISO 20022 response, e.g. a negative **pacs.002**, a negative **acmt.024** or a **camt.029** |

#### Common rules

These rules apply in both directions:

* **Technical vs business rejections.**
  * admi.002 is used only for **technical** problems with the message itself, such as a missing element, an invalid code or a wrong format.
  * **Business** outcomes on a valid message (for example, agent not found, duplicate payment or proxy not resolved) are reported with the normal ISO 20022 response instead, such as a negative pacs.002 or a negative acmt.024.
* **One rejection, one message.** Each admi.002 rejects one message, identified by its `MsgId` in `RltdRef/Ref`.
* **First response wins.** For each message, only one response is valid: a business response (pacs.002, acmt.024 or camt.029) or an admi.002, never both. The receiver acts on the first one it receives. Any later response for the same message is ignored and logged.
  * Importantly for pacs.008: for instance, if the Destination IPSO has already sent a pacs.002 `ACCP`, a later admi.002 can’t unwind the payment.
* **Three reason codes.** `Rsn/RjctgPtyRsn` is always one of:

| CODE   | NAME               | USED FOR                                         |
| ------ | ------------------ | ------------------------------------------------ |
| `FF02` | SyntaxError        | The message breaks a Nexus Usage Guideline rule. |
| `AG09` | PaymentNotReceived | A response does not match any open request.      |
| `DS28` | ProcessingError    | An internal error at the rejecting party.        |

* **Clear description.** `Rsn/RsnDesc` states the validation, the XPath of the failing element and a short explanation.
* **Message Definition**. is based on ISO20022 admi.002.001.01.
* **Final.** An admi.002 ends processing of the rejected message. An admi.002 is never rejected with another admi.002.