> ## 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

> Where Melio checks the business and the payment, how you see the result, and what can block a payment.

Melio runs the KYC, KYB, 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 (KYC, KYB, 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 `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 blocked during review, with no separate status. Device and IP signals from the [Sonar SDK](/docs/docs/sonar) 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>