A treasury team that has moved its first dollars into stablecoins usually discovers the same thing within a quarter: the conversion was the easy part, and the work that remains is the repetition. Somebody is logging in on Monday to sweep Friday's collections, somebody else is funding a subsidiary by hand because the rate looked acceptable that morning, and the month closes with a spreadsheet that reconstructs what happened.
Automating that is less about scripts than about deciding, in advance, what should happen without a human and what should never happen without one. The single conversion, and what it legally is in Brazil, is covered in converting BRL to USDC for treasury. This is the layer above it.
What automation means here
Three parts, and confusing them is why treasury automation projects stall. A trigger is the event that starts the flow: money landing in an account, a date, a balance crossing a threshold. A rule is the policy that decides what happens, including the amount and the currency. A destination is where the money ends up, which in a regulated flow has to be an account somebody has already verified.
Most teams start by automating the trigger and leave the rule in a person's head. That gets you a system that moves money on schedule and still needs somebody to decide how much, which is the expensive half. Write the rule down first. If the rule cannot be written down, it is a judgment call, and judgment calls belong in the section on what to keep manual.
The flows worth automating first
Deposit sweeps. Collections land in local currency through the day and sit exposed to the currency you did not want. A rule that converts every qualifying deposit as it arrives removes both the exposure and the Monday login. This is the highest-value automation for most companies and the simplest, because the trigger is unambiguous.
Intercompany funding. A subsidiary that needs working capital in its own currency, funded from a parent balance, on a cadence. The transfer itself is trivial. What takes the time is the paperwork underneath it, which is why the next section is about modelling the group before writing any rule.
Supplier settlement. Holding working capital as a dollar balance and paying invoices out of it across whichever rail the supplier banks on. The automation here is usually partial: the funding is automatic, the release is approved.
Balance floors. Keeping a minimum in a given currency so that an outbound payment never waits for a conversion. Simple to state, and the rule needs a ceiling as well as a floor, or you will find the treasury holding more of a currency than the policy allows because nothing ever told it to stop.
Model the corporate group before you write a single rule
This is where treasury automation actually goes wrong. The question is whether each legal entity holds its own balance or whether the parent holds everything and moves money out to entities that are related to it.
If each subsidiary holds its own balance, each one is onboarded as its own business customer, gets its own wallet, and money moves between them as internal transfers. That structure costs more to set up and is worth it when the entities file separately, because the balance sits where the accounts say it does.
If the parent holds everything, the related destinations are registered under the parent with the relationship declared: the same legal entity, the holding company above it, or a subsidiary below it. That declaration is not bureaucracy for its own sake. It is what lets a transfer be categorized correctly when somebody asks later why money moved from a Brazilian entity to a United States one, and it is the difference between an intercompany transfer and a payment to a third party. Custody of the balances themselves is a separate decision, set out in what a custodial wallet is.
A quote is not a rate you can act on
Every automated conversion has a moment between deciding the amount and the money actually moving. If the flow reads a rate, writes a record, and then executes, the rate that ends up in the ledger is not the rate that was quoted, and the difference shows up as an unexplained variance at month end.
The fix is to lock the rate and carry its identifier into the transaction, so the conversion executes against the rate the system already recorded. Treat any flow that quotes and executes as separate steps without a lock as a flow that will produce reconciliation noise, in an amount proportional to your volume and to the volatility of the pair. For the USD and USDC leg, where the pair is close to one, this matters less than for a leg through USD to USDC into a local currency, where the second conversion carries the real spread.
Calendars break more automation than code does
A rule that says "sweep every day at 6pm" is written by somebody who has only worked with one rail. Pix (Brazil's instant payment system, run by the Central Bank) runs continuously, including weekends and holidays, so a Brazilian sweep genuinely can run every day. SPEI (Mexico's interbank transfer system, run by Banxico) follows the Mexican banking calendar. ACH and wires in the United States follow the Federal Reserve's, published as Holidays Observed K.8, which lists eleven holidays for 2026 and carries a rule that catches people out: a holiday falling on a Sunday closes every Federal Reserve office the following Monday.
So an automated flow needs to know, per rail, whether today is a settlement day and what happens to an instruction submitted when it is not. Queued until the next business day is the usual answer, and it is fine as long as your own systems expect it. What is not fine is a flow that treats a queued payment as a failed one and retries, which is how a supplier gets paid twice.
The rule I keep coming back to is the least sophisticated one in this whole list: the first payment to a new destination is worth sending by hand, small, with somebody watching. Automation validates the format of an account identifier and cannot validate that it belongs to the company you think it does. A transposed digit passes every check in the system and is discovered when the money arrives somewhere else, at which point recovery depends on another bank's goodwill rather than on your controls. The delay it costs is small, and I have not often wished it away.
What to keep manual
Anything that is a decision rather than a policy. Changing the ratio of currencies the company holds, funding a new entity for the first time, paying a counterparty nobody has paid before, and any payment above a threshold that your own board would want to know about.
There is also a case for keeping a flow manual because the volume does not justify it. Two conversions a month do not need a rule engine, and building one produces a system that nobody remembers how to change a year later. Automate the flows that repeat weekly or faster, and leave the rest to a person with a checklist.
The wrong reason to keep something manual is that nobody has written the policy down. That is not caution, it is a policy that exists only in somebody's head, and it leaves with them.
Running these flows on Lumx
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.
The sweep is a rule on the account rather than a job in your code: an autoconversion rule converts every deposit that lands in a given account into stablecoin as it arrives, instead of your system creating a conversion per deposit. Each matched deposit still runs as a normal on-ramp transaction, so it emits the same events and produces the same receipt, with the exchange rate and the fees itemized.
The group structure is modelled through customers and destinations, in the two shapes described above. Each entity's balance sits in its own wallet, described in custodial wallets, and moves between entities as internal transfers rather than as a payout and a collection. Payment purposes are declared per transaction, including a code for moves between accounts of the same legal entity, a loan code that also covers an intercompany capital injection, and a trade code for supplier invoices, which is what makes the categorization survive into your own reporting.
Two operational details that matter for anyone writing rules. Rates can be locked ahead of a payout and the transaction executed against that locked rate, so the figure in your ledger is the figure that was quoted. And there is no batch endpoint: a run of payouts is one call per payment, each with its own idempotency key, which is a constraint on how you build your job runner and an advantage when one payment fails and the other forty do not. Changes to any of this are published in the dated changelog.
Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Eric Prouzet on Unsplash.
What is the first treasury flow to automate?
The deposit sweep, converting local currency collections into a dollar-denominated balance as they arrive. The trigger is unambiguous, the rule is one line, and it removes currency exposure that otherwise accumulates through the day. Everything else benefits from having that balance already in place.
Can I automate payments to new suppliers?
You can, and it is worth not doing for the first payment to each new destination. Account identifiers pass format validation while still pointing at the wrong company, and the error only surfaces when the money arrives. Send the first one small and by hand, then automate the recurring ones.
How do stablecoin treasury flows handle weekends and holidays?
It depends entirely on the rail. Pix runs continuously, so Brazilian flows can settle on a Sunday, while United States and European rails follow their own banking calendars and queue instructions submitted outside them. Build the calendar into the rule rather than assuming that a payment submitted today settles today.
Does automation change the regulatory position of these conversions?
No. A conversion between a local currency and a foreign one is the same regulated operation whether a person or a rule initiates it, and it runs through an institution authorized for that activity either way. What automation changes is the volume of records you produce, which is a reconciliation question rather than a licensing one.
