# CEP Statuses

Penny Validation resolves asynchronously. This page explains the full lifecycle
of a validation and the `status` values you can receive along the way, so you
can model it correctly on your side.

The same values appear in `metadata.dataCep.status` on API reads and in the
[CEP webhook event](/products/fincore/guides/webhooks#cep-webhook-event). To read the current value,
use [Retrieve a transaction](/products/fincore/guides/transactions#retrieve-a-transaction). For the
request contract, see [Penny Validation](/products/fincore/guides/penny-validation).

## End-to-end lifecycle

1. **You start the validation.** Call
[Create Penny Validation](/products/fincore/guides/penny-validation#create-penny-validation).
Monato sends a `0.01` MXN transfer to the destination instrument.
2. **You get a synchronous response.** This response only confirms the request
was accepted. It is not the validation result, and `metadata.dataCep.status`
starts as `INITIALIZED`.
3. **The transfer settles.** Only after settlement can a CEP exist for it.
4. **Monato retrieves the CEP from Banxico.** How long this takes depends on the
beneficiary's bank and varies significantly between institutions.
5. **You receive CEP webhook events as the status changes.** A single validation
can produce more than one event before it finishes.
6. **The validation ends as `COMPLETED` or `FAILED`.** `COMPLETED` carries the
verified account holder data you asked for.


Treat the validation as unresolved until you receive a terminal status. Drive
your flow from the webhook, not from the synchronous response.

## Status values

| Status | Meaning | Terminal |
|  --- | --- | --- |
| `INITIALIZED` | Transient state right after the validation is created. Appears on API reads only; the webhook never emits it. Treat it exactly like `PENDING`. | No |
| `PENDING` | The CEP lookup is in progress and the result is still expected within the usual window. | No |
| `DELAYED` | The CEP is taking longer than usual. Lookups continue automatically in the background. No action is required from you. | No |
| `COMPLETED` | The CEP was retrieved and the ownership data is available. | Yes |
| `FAILED` | The CEP could not be obtained, or the underlying transfer was rejected. | Yes |


Do not build distinct flows for `INITIALIZED`. Collapse it into `PENDING` in
your logic and UI.

## Status flow

```
INITIALIZED
     ├── PENDING ──── DELAYED ──── FAILED
     │      │            │
     │      └── COMPLETED┘
     │
     └── FAILED   (underlying transfer rejected)
```

What this guarantees for your integration:

- A validation always ends in `COMPLETED` or `FAILED`. It never stays open
indefinitely.
- `COMPLETED` and `FAILED` are final. Once reached, the status is never
overwritten, so a late event cannot move a validation back to `PENDING` or
`DELAYED`.
- `COMPLETED` can be reached from any non-terminal state, as soon as the CEP
becomes available.
- `PENDING` always precedes `DELAYED`. Seeing `DELAYED` does not mean anything
went wrong; it means the CEP is taking longer than usual.
- If the underlying transfer is rejected, the validation goes straight to
`FAILED` without passing through `PENDING` or `DELAYED`. No CEP is generated.


## Handling each status

| Status | Recommended handling |
|  --- | --- |
| `INITIALIZED`, `PENDING` | Show the validation as in progress. Wait for the webhook. |
| `DELAYED` | Keep waiting. Surface it as "taking longer than usual" if your UI needs to explain the wait, but do not treat it as an error or start a new validation. |
| `COMPLETED` | Read `beneficiaryName` and `beneficiaryRfc` to confirm ownership, and store `cepUrl` for your records. |
| `FAILED` | Treat ownership as unverified. Starting a new validation is a business decision; the account may simply belong to a slow bank. |


While a validation is `PENDING` or `DELAYED`, Monato keeps working on it in the
background until it reaches a terminal status. You do not need to poll or
re-send anything; every status change arrives as a webhook event.

Starting a new validation does not speed up a pending one. It creates a separate
`0.01` MXN transfer and a separate validation record.

## Field notes

`processedAt` is set whenever the validation record is updated, including
intermediate updates. Do not use it as a signal that the validation finished;
use `status` for that.

For field optionality and forward-compatible parsing, see
[Core Concepts](/products/fincore/guides/concepts#field-presence-and-compatibility).

## Related pages

- [Penny Validation](/products/fincore/guides/penny-validation)
- [Webhooks](/products/fincore/guides/webhooks)
- [Error catalog](/products/fincore/guides/error-catalog)