The question that decides a custodial wallet structure is not how many wallets you need. It is what each wallet corresponds to in the real world, because that mapping is what an auditor, a regulator and your own finance team will read it against. A structure organized around engineering convenience produces balances that no statement can explain.
This is the layer above what a custodial wallet is, which covers who controls the assets and what the law makes of that. Here the assumption is that you have accepted provider custody and now have to lay it out for an institution that has subsidiaries and an audit cycle.
One wallet per what
The only mapping that survives contact with accounting is one balance per legal entity. Not per product, not per team, not per country office unless that office is a separate company. The reason is that every question anyone will ask about the balance is a question about a legal entity: which company owns it, which set of accounts it appears in, which tax authority has an interest in it, and who is authorized to move it.
Teams reach for other mappings because they solve a display problem. A wallet per business unit makes an internal dashboard easier. It also means that when the group files, somebody has to reconstruct the entity view from the business unit view, every period, by hand. Build the entity view as the real one and produce the business unit view as a report over it.
The corollary is that a wallet belonging to a party who is not a verified customer of the provider is not a structure, it is a liability. Funds held for parties the provider has never identified are the arrangement that compliance reviews are designed to find.
The two shapes, and how to pick
Entity per balance. Each subsidiary is onboarded as its own business customer and holds its own wallet. Money moves between group companies as internal transfers, each one a record with a payer and a payee that already exist. This is the right shape when subsidiaries file separately, when local management has authority over local cash, or when any part of the group may be sold.
Parent holds everything. One customer, one balance, and the related companies are registered as destinations under the parent with the relationship declared: the same legal entity, the holding company above, or a subsidiary below. Simpler to set up, fewer verifications to maintain, and it works when the group operates as a single treasury and the subsidiaries are cost centres in practice.
The mistake is picking the second because the first looks like more work, then discovering at year end that an intercompany movement was recorded as a payment to a third party because nobody declared the relationship. The declaration costs one field at setup and is the difference between a transfer your accountant can classify and one they have to ask about.
Multi-level ownership is a separate axis and it does not change the wallet structure. A company owned by a fund that is owned by individuals is verified by nesting the shareholders under each other, which affects the onboarding work rather than where the balances sit.
Limits belong in the design, not in the incident report
Every provider applies limits per customer: a maximum per transaction, per day and per month. Institutions discover them in one of two ways. Either the limits are visible in the system, with the amount used and the amount remaining, so a payment that would breach one is knowable before it is attempted. Or they are discovered when a payout fails at the worst possible moment.
Design against the first. Read the remaining amount before a large movement, and treat a raise as a process with a lead time rather than a support ticket. A raise is usually supported by a document that evidences the volume, such as a bank statement, and it can come back approved, approved at a lower number than requested, or rejected with a reason. A treasury that assumes approval and schedules a payment against the higher figure has built a dependency on somebody else's review queue.
What the auditor will actually ask for
Four things, and a structure that cannot produce them will cost you time in every audit cycle.
A list of balances by legal entity at a point in time. A record of every movement in the period, with counterparty, purpose and the rate applied where a conversion happened. Evidence that the entity in your accounts is the entity the provider verified, which means the legal name and tax identifier matching across both. And a description of who can initiate a movement, who can approve one, and how that is enforced.
That last one is where institutional structures are weakest. Provider custody moves the signing question to the provider, and it does not move your own authorization question anywhere. Whoever holds your API credentials can initiate. If that is one key shared by a team, your segregation of duties exists in a policy document and nowhere in the system.
I have watched this specific gap embarrass people more than any other, and it is never discovered during the integration. The integration is done by engineers, who correctly treat a credential as a credential, and the control question arrives months later from a finance lead preparing for an audit. My position now is that the approval layer is the client's own product surface and it should be built in the same sprint as the payout, not in the one after, because the version that gets built later is the version that gets built under time pressure.
When this is the wrong structure
If the institution's requirement is that no third party can move the assets under any circumstances, a custodial arrangement does not meet it, and no amount of structure will change that. The tradeoff is real and it is set out in the custody explainer. Some mandates, particularly funds with specific custody obligations, simply cannot be served this way.
It is also wrong when the balances are large and static. Custody arrangements built for payment operations are optimized for movement, and an institution that wants to hold a treasury reserve untouched for a year is buying operational capability it will not use. The question worth asking is how often the money actually moves.
And if the entity structure itself is unsettled, wait. Onboarding six subsidiaries and then reorganizing the group means verifying them again. Where the open question is regulatory status rather than corporate structure, the activity itself may need a VASP (virtual asset service provider, the FATF term) authorization, and which activities require one sets out the test per jurisdiction. Which countries a group can actually hold balances and pay out in is on the coverage page.
Structuring this 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 unit is the customer. Creating one provisions a wallet on each supported blockchain, and those wallets are enabled for use once verification is approved, which means the structure and the compliance state are the same object rather than two systems that have to agree. A balance persists between operations, so an entity can be funded once and pay out from that balance repeatedly.
For a group, the two shapes described above map directly. Multi-entity means one business customer per subsidiary, each with its own wallet, with movements between them as internal transfers. Single-entity means the parent holds the balance and each related destination is registered under it with the relationship set to the same entity, the holding company, or a subsidiary. Transaction limits are readable per customer through the API, including the amount used and the amount remaining against the daily and monthly ceilings, and a raise is requested with a supporting document and can come back partially approved.
The constraint worth stating explicitly, because it shapes any institutional design: a payout debits the wallet of the customer it belongs to, into a destination registered under that same customer, or transfers to another onboarded customer. Client trust accounts, escrow for beneficiaries who have not been identified, and pooled structures holding funds for parties we have not onboarded are outside what the platform supports. Brazilian law treats custody of virtual assets as a service in its own right, under Law 14.478 of December 21, 2022, whose Article 5 lists it among the five virtual asset services. The full shape of the wallet product is on the custodial wallets page, and the flows that run on top of this structure are in automating treasury with stablecoins.
Verified on September 24, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Frantisek Duris on Unsplash.
How many wallets should an institution have?
One per legal entity that needs to hold a balance in its own name. Mapping wallets to business units, products or teams creates a reporting layer that has to be reconciled back to entities every period. Build the entity structure as the real one and generate other views as reports.
Can subsidiaries move money between themselves?
Yes, when each subsidiary is onboarded as its own customer. The movement is an internal transfer between two parties the provider has already verified, which is cleaner to record than a payout followed by a collection. If the parent holds all balances instead, the related destinations are registered under the parent with the relationship declared.
Who can authorize a movement in a custodial structure?
Whoever holds the credentials that call the API, which is why the approval layer has to be built on the client side. Provider custody answers the question of who signs on the blockchain and answers nothing about who inside your company may initiate a payment. Treat that as part of the integration rather than as a later addition.
What does an auditor need from a custodial wallet structure?
Balances by legal entity at a point in time, a complete movement record with counterparties and applied rates, evidence that the verified entity matches the one in your accounts, and a description of initiation and approval controls. A structure organized around entities produces all four directly.
