Cross-border payments in LATAM: holidays and cut-offs

This content is provided for informational purposes only. It does not constitute financial, legal, tax, or regulatory advice. Each company should evaluate its implementation with its own internal teams and professional advisors. Holiday calendars and rail behavior described here reflect information available as of September 2026; confirm critical dates with your Treasury and Compliance teams before scheduling payments. 

On April 3, 2026, banks in Mexico, Brazil, Colombia, and Argentina all close on the same day. It isn't a coincidence anyone put on a shared calendar, it's Good Friday, observed as a bank holiday in all four markets at once. If your company runs payroll, pays suppliers, or moves treasury balances across any of these countries, that's the kind of date that turns a routine payment into an exception report.

Cross-border payments in Latin America move through some of the fastest payment rails in the world. But speed inside the rail doesn't remove the calendar around it. Bank holidays, cut-off windows, and settlement timing still shape when a payment actually lands, and each country keeps its own version of all three. This guide maps the 2027 bank holiday calendar for Mexico, Brazil, Colombia, and Argentina, explains how each local rail actually behaves around it, and shows how to design a payment calendar that plans for that instead of finding out the hard way.

Before comparing rails, it helps to see just how different these four calendars really are.

Why LATAM's payment calendar isn't one calendar 

Treasury teams used to a single home-market calendar often assume a LATAM calendar works the same way: a short list of fixed dates, mostly aligned with the rest of the world. In practice, each country sets its own holidays, its own rules for moving them, and its own density of long weekends.

None of this means the underlying payment rail stops. What actually changes around a holiday is what surrounds the rail: branch hours, FX desks, compliance review capacity, and correspondent banking. That distinction is the one most payment calendars miss.

The rail that never sleeps vs. the process that still does

Where the calendar actually breaks payroll and mass payouts

A missed date rarely comes from the rail failing. It comes from a mismatch between when your company expects a payment to land and when everything around the rail is actually open to make that happen.

A few patterns show up again and again:

• A payroll batch is scheduled to fund the day before a long weekend, but the FX desk that prices the conversion is already closed for the holiday.
• A supplier payment clears in Mexico or Brazil in minutes, but the compliance review queue is backed up because the team is short-staffed ahead of a holiday cluster.
• A mass payout to contractors goes out late at night and lands short, not because it failed, but because it hit Pix's nighttime value cap.
• A batch aimed at Colombia assumes one calendar, and lands squarely inside one of the 13 long weekends the Ley Emiliani creates.

None of these show up as an error message. They show up as a support ticket, a frustrated employee, or an exception your reconciliation team has to explain after the fact. For companies running mass payouts in Latin America at scale, across payroll, suppliers, and gig payments, that's where a calendar built for one country quietly breaks in another.

Where an API for cross-border payments in LATAM removes the guesswork

Manually tracking four holiday calendars, plus each rail's cut-off logic, is not a realistic ongoing task for a payments or treasury team, especially as the number of markets grows. This is the problem a single API for cross-border payments in LATAM is built to absorb: instead of your team maintaining a spreadsheet per country, the integration already encodes each market's holidays, cut-off windows, and settlement behavior, and adjusts batch scheduling accordingly.

In practice, that means a payroll run submitted two days before a Colombian long weekend gets routed to settle before the gap, not after it. It means a nighttime mass payout to Brazil respects the Pix value cap instead of failing silently. And it means your team plans around one calendar, the one your provider maintains, instead of four.

Stablecoins as the buffer around bank hours

Some gaps aren't about the local rail at all, they're about what funds it. A traditional USD wire depends on correspondent banks that observe their own holiday calendar, in the U.S. and in the destination country. When both calendars have to line up for a wire to move, a single holiday on either side can push a payment to the next business day, even though the local rail on the receiving end never stopped running.

This is where stablecoins for business payments change the equation. Funding in USDC removes the dependency on a correspondent wire's business hours: the transfer of value itself doesn't observe a bank holiday. From there, converting through USDC to MXN liquidity and paying out over SPEI, or through the equivalent local rail in Brazil, Colombia, or Argentina, lets Treasury execute on a weekend or a holiday that would otherwise stall a traditional wire. It doesn't eliminate the local calendar; Mexico's holidays still close branches and FX desks. What it removes is the extra day some corridors lose to a wire that was waiting on a calendar it didn't need to.

Building a payment calendar that doesn't fail

FAQs
 

Do SPEI, Pix, and Bre-B really process payments on bank holidays?

Yes. All three are built to run continuously, 24 hours a day, 365 days a year, including official bank holidays. What closes on a holiday is everything around the rail, bank branches, FX desks, and often compliance review capacity, not the rail itself.

What happens to a mass payout scheduled for a bank holiday?

The local rail typically still processes it. The risk usually sits earlier in the flow, in whether FX pricing, compliance review, or funding happened before the holiday closed those steps down, not in the local transfer itself.

Why did a Pix payout get capped when it was sent at night?

Brazil's Central Bank requires lower transaction limits during nighttime hours, roughly 8 p.m. to 6 a.m., for standard and new-device transfers, as a fraud-prevention measure. A payout sent in that window can land under your usual limit even though Pix itself never stopped running.

Does using stablecoins remove cut-off risk completely?

No. It removes the specific gap created by a correspondent wire waiting on a bank holiday it didn't need to observe. Local holidays that close branches, FX desks, or compliance teams still apply, and rail-specific limits like Pix's nighttime cap still apply regardless of how you funded the payment.

How Bitso Business fits into calendar planning

A single provider doesn't remove the calendar, it absorbs the work of tracking it. Bitso Business connects to local rails including SPEI* in Mexico, so payroll, supplier, and mass-payout schedules can be planned around one integration instead of four separate calendars, four cut-off logics, and four sets of compliance queues.

*NVIO México enables direct access to SPEI and delivers payment services fully compliant with Mexican regulation. NVIO Pagos México, S.A.P.I. de C.V., IFPE (“NVIO México”) is authorised and regulated by the Mexican National Banking and Securities Commission (CNBV). Learn more at nvio.mx/terms.