The Pix transfer limit for a company, and cut-offs by rail

The question that brings most teams here is how much a company can move over Pix (Brazil's instant payment system, run by the Central Bank) in a day, and the answer is that the ceiling they will actually hit is not a property of the rail at all. It is a property of the customer and of how far that customer's verification went. Cut-offs work the other way round: they belong to the rail, they have nothing to do with who is sending, and they are the same for everyone on it.

Getting those two backwards is what produces a payment run planned against the wrong constraint. The rest of this is what is published for each one, and what is not.

The limit belongs to the customer, the cut-off belongs to the rail

A transaction limit caps how much a given customer can move per transaction, per day and per month, and the tier of verification that customer completed is what sets it. The same customer hits the same ceiling whether the payment goes out over Pix, SPEI (Mexico's interbank transfer system, run by Banxico) or a wire, because the limit is attached to them.

A cut-off is the daily deadline after which a request is processed on the next business day in the rail's own jurisdiction. It is attached to the rail. Sending more money does not move it, and being a larger customer does not either.

Two different owners, two different escalation paths. A limit is raised through verification and a documented request. A cut-off is worked around by scheduling, or by choosing a rail that does not have one.

What the published limits are

Ceilings are stated in US dollars and sit against the verification tier rather than the currency being moved. KYB (know your business, the verification of a company and its owners) covers companies and KYC (know your customer, the verification of an individual) covers individuals, and each has a standard and an enhanced tier.

Published transaction limits by verification tier, in USD

The enhanced columns are open-ended on purpose. Once a customer completes enhanced verification, the limit set is the one that fits the financial capacity shown in the documents they submitted, so there is no single published number to quote. A company asking what its ceiling will be after enhanced KYB is asking a question that only its own documents answer.

Note the shape of the standard business tier: the daily and monthly ceilings are the same figure. A business customer that moves its full daily allowance has also moved its full month, which is a constraint that catches teams planning a monthly payroll before it catches teams planning a daily one.

Read the remaining limit before you send, not after

A rejection for exceeding a limit is avoidable, because the numbers are readable in advance. Reading a customer with transaction limits included returns the per-transaction ceiling alongside the used and remaining amounts for both the daily and the monthly window.

Build the check into the product rather than into support. A payout screen that knows the remaining daily allowance can tell a customer to split a batch before they submit it, which is a better experience than a refusal after the fact and a much better one than a partially completed run. What happens when you skip that check is catalogued in why a stablecoin payout gets rejected.

Raising a limit is a process, not a negotiation

Higher limits come from enhanced verification plus a documented request, submitted from the dashboard or through the API. The request states the new per-transaction, daily and monthly figures, and carries a supporting document that has to justify them: a bank statement, financial statements or a tax return for a business, a bank statement, tax return or proof of income for an individual. Accepted formats are PDF, JPG, JPEG and PNG, up to 10 MB.

Four outcomes are documented. Approved grants the request in full and takes effect immediately. Partially approved grants less than was asked for, based on what the document supports, and also takes effect immediately. Rejected leaves the customer on current limits. RFI (request for information, a compliance hold that asks for a document before a transaction clears) means the document was insufficient and the request needs resubmitting.

The published review timeline is one business day, described as a target rather than a commitment, with larger step-ups and unusual documents taking longer. That is short enough to be worth planning around and long enough that discovering the need during a payment run is already too late.

Cut-offs and settlement windows by rail

These are published per rail and they are the numbers to schedule against.

Cut-off times and settlement, by rail

The timezone arithmetic is where this bites. An off-ramp triggered at 4:00 PM in São Paulo has already missed the 3:00 PM ET FEDWIRE deadline, so a payment that felt like it went out mid-afternoon is a next-business-day payment. Teams running a single daily batch out of a Brazilian or Mexican office should set the batch time against the destination rail's clock rather than their own.

The Brazilian and Mexican rails have no cut-off and no weekend, which is the part that surprises people coming from correspondent banking. A Pix payout at 2:00 AM on a Sunday settles the same way it would on a Tuesday morning.

Bank holidays are published, maintenance windows are not

Each rail follows its own jurisdiction's calendar, and a transaction submitted on a recognised holiday is queued for the next business day. ACH, FEDWIRE and SWIFT follow the US federal holiday schedule published by the Federal Reserve. SEPA follows TARGET2 closing days published by the European Central Bank. SPEI follows the días inhábiles bancarios published by Banxico. Pix follows none of them, because it does not close, though Brazilian holidays can still affect dispute windows.

Maintenance windows are a different story, and the honest answer is that there is no published schedule of them. Our documentation lists what can extend a timeline, and the list is compliance review, bank holidays, intermediary banks on wires, extra risk review on large transactions and holds by the receiving institution. Scheduled downtime is not on it. Anybody publishing a maintenance calendar for these rails is either describing their own platform or making it up, and this post is not going to do the second thing to fill out a heading.

Treat that as a planning input rather than as a gap to work around. A payment run whose success depends on a specific ten-minute window is fragile for reasons that have nothing to do with maintenance, and the fix is the same either way: idempotent retries and a run that can resume.

What the published tables will not tell you

They will not tell you the minimum. There is an error code for an amount below the supported minimum for a currency, so a floor exists per currency, and the figure is not published. Find it in the sandbox for the currencies you actually use rather than assuming.

They will not tell you the rate limit on the API either. A code exists for exceeding it, and no threshold is documented, so the correct client behaviour is exponential backoff on a 429 rather than a request budget computed from a number nobody published.

And they will not tell you when the money arrives, only when it leaves. Delivery is considered complete once funds leave our banking partner, and the receiving institution can hold them for its own review after that. On a wire, intermediary banks can add hours or days on top and deduct fees nobody upstream controls. Large transactions can pick up an extra risk review, typically adding up to two business hours. Every one of those is outside the table, and the corridor mechanics behind them are in what a stablecoin corridor is.

My planning rule is to schedule against the cut-off and communicate against the settlement window, never the other way round, because the cut-off is the only one of the two that is fully inside our control. The second half of that rule is that I would rather publish a slower promise we hold every time than an average we beat most of the time, since a payments operation is judged on its worst week. That is also why the qualifications above are in the documentation instead of a footnote: an operator planning a run needs the failure modes more than they need the headline number.

Planning a run with us

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

Because the payout debits a stablecoin balance the customer already holds, the funding leg and the delivery leg come apart. Fund the wallet whenever it suits your treasury, then release payments against the destination rail's clock. A run that has to land in Brazil on a Sunday is a Pix run. A run that has to land in the United States today is a FEDWIRE run submitted before 3:00 PM ET, and the same run at 3:30 PM ET is tomorrow's.

Which rails are live for which currency is on the rail coverage page, and how the legs fit together per country is in global payments. The mechanics of the payout itself, including what the customer sees at each state, are in what a stablecoin off-ramp is.

Methodology and sources

Limits, tiers, accepted documents and review outcomes are from the Lumx transaction limits page and the limit increase guide. Cut-offs, settlement windows, operating days, the list of things that extend a timeline and the holiday calendars per rail are from the Lumx payment rail cut-off page. All were read on September 24, 2026, and the error codes referenced are from the published error catalog read the same day.

Two claims in this post are negative and were checked rather than assumed. There is no published maintenance-window schedule for these rails in the documentation as of that date. There is no published per-currency minimum amount and no published API rate-limit threshold, though error codes exist for both. If any of those get published, this post is out of date and should be corrected rather than defended.

Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Antje Winkler on Unsplash.