Dates and time zone

Every API timestamp is in UTC, expressed as ISO 8601 with a Z suffix:

"created_at": "2026-08-21T14:32:09Z"

This covers all temporal fields — created_at, updated_at, expires_at, last_delivery_at, dispatch_at — with no per-operation exception. The only caveat is the date and time that the CEP prints, described at the end of this page. Converting to the user's zone is the client's job.

The guarantee travels on every response, inside the meta block described in the response shape:

"meta": { "datetime": { "timezone": "UTC", "format": "ISO 8601" } }

It is there so the fact can be asserted at runtime, rather than re-read from the specification on every release.

Date filters

Range parameters accept two forms:

A bare date is never interpreted in the caller's local zone or the server's. A from=2026-08-01 filter covers the month from UTC midnight, not from Mexico City midnight.

That difference matters at the edges of the range: in zones west of UTC, a report filtered by local day loses its first hours if the date is sent unadjusted. The adjustment belongs to the client, which knows the user's zone.

Sending date and operation date

A SPEI transfer has two dates, and the API uses each one in a different place:

• Sending date: The day the transfer was made. It is the request's fecha field and Banxico locates the CEP with it. It is sent as a bare date, with neither time nor zone.
• Operation date: The SPEI business day Banxico assigned the transfer to. The CEP prints it and it comes out in banxico_result.operationDate, with its time in banxico_result.processingTime.

SPEI operates every day, but the business day changes at 18:00, Mexico central time: what is sent from that hour on, on a Saturday, on a Sunday, or on a non-business day operates on the next business day. A transfer sent on Saturday at 22:48 has Monday as its operation date.

operationDate and processingTime are not in UTC: they come out as the CEP prints them, in Mexico central time. They are not compared with created_at or completed_at without converting them first.

When Banxico does not find the payment with the date sent and does find it with another, the validation keeps the finding in banxico_result._fecha: used is the date it was found with, requested the date first queried, and reason the motive. request_data.fecha remains the one sent. The values of reason are in the response of GET /v1/validations/{id}.

Non-business-day calendar

GET /v1/public/spei-calendar/{year} returns the non-business days of a year that fall from Monday to Friday, with the provision of the Comisión Nacional Bancaria y de Valores (CNBV) they come from. Saturdays and Sundays are also non-business days and are not repeated in the list. The request does not consume validation quota.