> ## Documentation Index
> Fetch the complete documentation index at: https://developers.staging01.melio.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Risk and compliance

Melio runs the AML, sanctions, and payment-risk checks for you. This page explains where those checks happen, how you find out the result, and what can block a payment.

## Entity validation

When you create an entity (`POST /entities`), Melio validates the submitted fields. If a field has the wrong type or fails a rule, the request returns `400` with field-level detail in the error `details`, naming the field and the problem. A common case is a tax-id type that does not match the business formation type.

## Business eligibility (AML, sanctions)

Melio screens the business and its owner (the owner's name and date of birth are collected for sanctions screening). The result is exposed continuously through the **limitations endpoint**:

```http theme={null}
GET /limitations
```

Each write operation is reported as `allowed: true`, or `allowed: false` with one or more `reasons`. A reason carries a code and, when relevant, the fields that are missing.

| Reason code           | Meaning                                                                  |
| --------------------- | ------------------------------------------------------------------------ |
| `MissingInformation`  | More data is needed. `missingFields` lists what (for example `taxInfo`). |
| `AccountBlocked`      | The business is blocked from this operation.                             |
| `AccountUnderReview`  | A review is in progress.                                                 |
| `OutstandingBalance`  | An unpaid balance is blocking the operation.                             |
| `LocationRestricted`  | The operation is restricted for this location.                           |
| `AccountUnresponsive` | Melio needs a response from the business to continue.                    |

When eligibility changes, Melio sends `api.entity.updated` and `api.limitation.updated`. If information or documents are missing, Melio may contact the entity directly.

<Note>
  Some compliance fields are fixed once the entity is created: `legalName`, `legalAddress`, and `taxInfo`. Sending them in an update returns `400`.
</Note>

## What can block a payment

A payment can be stopped at several points:

| Check                                 | When                                                    | Result                                                                |
| ------------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------- |
| Business not eligible                 | On `POST /payments` (and on adding an internal account) | `403 BUSINESS_NOT_ELIGIBLE`                                           |
| Goods received not confirmed          | On card-funded `POST /payments` over \$3,000            | `400 GOODS_RECEIVED_REQUIRED`                                         |
| MCC missing for a card-funded payment | On `POST /payments`                                     | `400 MCC_REQUIRED`                                                    |
| Delivery preference not eligible      | On `POST /payments`                                     | `400` (a fast variant is never silently downgraded)                   |
| Payment risk review                   | After creation, while the payment is `scheduled`        | If not approved, the payment is declined and moves to `failed` status |

The risk review is the one that can stop a payment that already looked accepted: the payment stays scheduled during review, with no separate status. Device and IP signals from the [Sonar SDK](/docs/sonar-session-token) feed this decision.

## How to react

* **Check limitations first.** Read `GET /limitations` before adding accounts or creating payments, and surface `missingFields` to the business.
* **Handle the errors.** Treat `403 BUSINESS_NOT_ELIGIBLE` and the `400` compliance errors as user-fixable, not retryable as-is.
* **Subscribe to the webhooks.** `api.entity.updated`, `api.limitation.updated`, and `api.payment.updated` tell you when a decision changes.

<Card title="Sonar session token" icon="shield-halved" href="/docs/sonar-session-token">
  The device and IP signals that feed the payment risk decision.
</Card>