Local accounts without a local entity: how it actually works

"No local entity required" describes a commercial outcome. The structure that produces it is written down, and in Mexico it is written into the rules of the rail. Under those rules, an account is an accounting record kept by an authorized participant for a named holder, and every transfer is sent or received by the participant in that holder's name. Everything a finance team wants to know about the arrangement follows from that definition: who the holder of record is, when the funds are yours, what reconciliation matches on, and what the structure leaves unsolved.

Whose name is on the account?

The holder's. Mexico's instant payment rules define a Client Account as an accounting record, identified uniquely for each deposit account or other financial product in the rail's own product catalogue, that a participant keeps for the respective holder, to post the charges and credits of the transfer orders that participant sends or receives in the name and on behalf of that holder (Banco de México, Circular 14/2017, definition XXI, as amended through 2026). Two facts sit inside that sentence. The record is kept for the holder, and the act of moving money on the rail belongs to the participant.

That split is the whole arrangement, and the rulebook spells it out: the client is the holder of the record, the licensed participant is the entity authorized to transact on the rail, and the rules describe the participant acting for the holder, in the holder’s name. A definition for anyone reading this section on its own: a local account without a local entity is an account whose holder is your company and whose operating authorization belongs to your provider.

One account identifier per account, by rule

Participants must assign at least one CLABE to each Client Account they keep open for the financial products listed in the rail's product catalogue, and they must ensure each CLABE is distinct for each Client Account (Banco de México, Circular 14/2017, rule 9, as amended by Circulars 8/2019 and 1/2022). The CLABE (Clave Bancaria Estandarizada, or standardized bank account key) is an 18-digit number: three digits identify the institution, three the plaza (the locality), eleven the account, and one is a check digit that validates the structure.

Since 2022 the rules also describe how the arrangement scales beyond a participant's direct customers. A participant assigns sets of CLABEs to clients that hold the status of Indirect Participant, and assigns the digits that identify each of those Indirect Participants inside every CLABE, so that they in turn assign each of those CLABEs to the accounts of their own Indirect Clients (added by Circular 1/2022). What the rules describe there is a chain of records rather than a way around the authorization. The status of Indirect Participant is granted under the same rulebook, and every CLABE in the chain stays traceable to the participant that holds the authorization.

When does the money stop being the provider's?

At the level of the record, on every movement. The Client Account exists to post the charges and credits of each transfer order, so each amount lands against a named holder at the moment the order is processed, which is why a statement can be produced per holder rather than derived from a pooled total.

The rail then does something less widely known at the end of the day. For participants that are not credit institutions, the closing balances of their rail accounts are held in a concentration account at the central bank's own settlement system, without generating interest, and are credited back to the same accounts at the start of the next operating day (Banco de México, Circular 14/2017). Two consequences are worth writing into a treasury policy. Balances resting on the rail overnight earn nothing, by rule, so any yield story has to come from somewhere outside the rail. And funds return at the rail's next operating day, which makes the rail's calendar the thing that defines when money is available, ahead of any provider commitment.

One tracking key per transfer order

Reconciliation matches on identifiers the rail issues. Every transfer order carries an alphanumeric tracking key, lands in a Client Account that has its own distinct CLABE, and produces an electronic payment receipt generated from the order itself (Banco de México, Circular 14/2017). Reconciliation therefore matches on keys the rail assigns, each one tied to a single holder record, and the receipt comes out of the order rather than being reconstructed afterwards.

The practical test of a provider is whether those keys reach you. Inflows that arrive at one shared identifier and are separated afterwards by an internal note leave the matching work with your team, and no amount of reporting moves it back. What the rail assigns has to land in your own records with the key still attached. On ATTRUS the account is opened in the client's own name with the correct local identifier, agência and conta (branch and account) in Brazil, CLABE in Mexico, RUT and cuenta (tax ID and account) in Colombia. A single ledger holds the balances across currencies, and every state change produces a statement entry, a typed webhook and an audit trail.

What breaks when a local payer demands a local tax ID?

Less than most teams expect in Mexico, and the exception is written into the tax rules rather than negotiated. When there is no taxpayer key available, a Mexican electronic invoice carries the generic key XAXX010101000, and for operations carried out with residents abroad who are not registered in the taxpayer registry, the generic key is XEXX010101000 (Servicio de Administración Tributaria, Resolución Miscelánea Fiscal 2026, rule 2.7.1.23, published in the Diario Oficial de la Federación on 28 December 2025). A Mexican payer can invoice a foreign company that holds no local taxpayer key, using a key the tax authority defines for exactly that case.

What does break is narrower, and naming it is more useful than the reassurance. Anything that requires your company itself to be the registered local taxpayer stays out of reach: supplier registration processes that demand a domestic taxpayer key, withholding regimes written around a resident counterparty, and procurement at public bodies or large enterprises that verifies a vendor against a local registry. Those are tax and procurement questions, decided by the counterparty, and a payment rail does not answer them.

Three limits of the structure

The arrangement solves collection, holding and settlement in local currency. It leaves three things where they were, and a plan that assumes otherwise slips late.

1. No return on balances resting on the rail. Closing balances of non-bank participants sit at the central bank's settlement system without generating interest (Banco de México, Circular 14/2017). Returns on idle cash are a treasury decision made elsewhere, on instruments the rail has nothing to do with.
2. The authorization is not transferable. It belongs to the entity that holds it. Local consumer protection and securities regulation stay with your company, along with billing and the product itself; the financial-rail compliance is the part that moves to the regulated entity.
3. Local taxpayer status is not conferred. An account in your name on a local rail does not register your company with the local tax authority, and the counterparties that require that registration will still require it.

What to ask a provider

Three questions separate a described structure from a claimed one, and each has a verifiable answer.

• Which entity is the holder of the account, and which entity transacts on the rail? The useful answer names both, and names them separately.
• Does each account carry its own identifier, or do inflows land in a pooled one? At least one CLABE per Client Account, distinct for each account, is a rule on the Mexican rail, so a provider that pools inflows is choosing to, and the reconciliation cost is yours.
• Which entity, registration and supervisor apply in each country? A single answer covering three countries is not an answer. ATTRUS operates in Mexico and Colombia through locally compliant sponsor-institution frameworks, backed by registered local entities, with AML, KYC and foreign exchange controls aligned to local regulation, and in Brazil under its own payment-institution authorization. Every transaction passes through the same KYC, KYB, AML, foreign exchange and sanctions controls.