The pattern is common enough to be predictable. A firm starts with one company, adds a second because a target market requires a local licence, or because an existing licence cannot serve a segment it wants. Now there are two sets of terms, two capital positions, two sets of reporting, and one operations team that would like to run both from one screen. That last wish is reasonable. The way it is implemented is what a supervisor will look at.
Separation is not a philosophical point. Each entity has its own permissions, its own client money position, its own conduct rules and its own regulator, and the group is expected to demonstrate that a client of entity A is a client of entity A only. Where the platform blurs that, the firm is holding a compliance problem that no policy document fixes. Groups thinking about this at the corporate level should read it alongside two entity broker structures, because the technical build follows the legal one and not the other way round.
The five places separation has to be visible
Onboarding is the first. A prospect has to be assigned to one entity before an account exists, on rules the firm can defend: residence, the market being targeted, the product requested, the categorisation outcome. The assignment has to be recorded with its reason. A support agent who can move a client between entities with a dropdown, without a documented basis, has just created the exact evidence a supervisor does not want to see.
Contracts and disclosures are the second. Each entity has its own client agreement, its own risk warnings, its own complaints route and its own compensation position. The client must accept the right one, and the accepted version has to be retained. This is the mechanical side of terms of business by entity, and it is where firms most often get caught: one PDF, one company name, two regulators.
Trading conditions are the third. Leverage caps, product availability, marketing of bonuses and the treatment of negative balances differ by regime. If both entities share one symbol and group configuration, a change made for one becomes a breach for the other. Entity scoped configuration is the requirement, with changes logged per entity.
Money is the fourth, and the least forgiving. Client funds belong to the entity that owes them, in accounts held by that entity. A shared payment account across two companies is a problem that no accounting entry repairs. The processing side follows: acquirers underwrite a legal entity, not a brand, so each company typically needs its own merchant relationships and its own descriptor. Firms who assume one processor integration will serve both entities discover otherwise during underwriting.
Reporting and access are the fifth. Each entity's records need to be extractable on their own, and staff access should be scoped, so a person supporting only one entity sees only that entity's clients. This matters at audit and it matters more at exit: if the group ever sells or surrenders one licence, the ability to lift one entity's data cleanly is the difference between a transaction and a rebuild.
Structuring is legal work. Which entity may serve which client, and on what basis, is a question for counsel in every market involved. Nothing here is advice, and no platform configuration makes a structure lawful that is not.
Shared instance or separate deployments
There are two honest architectures and one bad one.
A single deployment with strict entity scoping works when both entities have compatible obligations and neither faces a data localisation or full separation requirement. Every record carries an entity identifier, configuration is scoped, staff permissions are scoped, and reporting filters by entity. It is cheaper, and one operations team runs both. The risk is that scoping has to be complete: one unscoped screen, one global setting, one report that mixes both, and the separation is only as good as its weakest page.
Separate deployments are the answer when a supervisor expects segregation, when hosting has to sit in a particular country, or when the two entities operate on materially different rules. It costs more and it duplicates operational work. It is also much easier to explain to a regulator, and much easier to unwind.
The bad option is one entity's platform with the second entity's name written over the top: shared accounts, shared money flow, shared client records, a different logo. It is quick, it is cheap and it is the version that turns into an enforcement narrative the moment somebody asks which company held the client's funds.
The traffic problem nobody solves in software
Two entity groups almost always face the same conflict: the offshore entity has the wider product set and the higher leverage, and clients in strictly regulated markets would prefer it. Routing those clients there is where firms get into trouble, and the trouble is not technical. Marketing an entity into a market where it is not permitted to solicit is a regulatory problem regardless of the platform, and the narrow carve outs are much narrower than founders hope, as anyone who has read the detail on reverse solicitation already knows. Build the platform so that the assignment rule the firm can defend is the assignment rule the system enforces, and make overrides visible.
What to ask before you build
Ask whether entity is a first class field across every object, or a tag added to accounts. Ask whether configuration, documents, email templates, payment routing and reports are all scoped. Ask whether one entity's data can be exported and deleted independently. Ask how a client is moved when a move is legitimate, and what evidence that move leaves. Our Broker CRM treats entity as a structural field for these reasons: the alternative is a firm discovering at audit that separation existed in the org chart and nowhere else.
Groups that build this properly report the same benefit later. When they add a third entity for a new market, the work is configuration rather than a rebuild, and the licence application answers the technology questions with a diagram instead of a promise.
"If the same login shows a client both entities, you do not have two entities. You have one, with two logos on it."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Separation has to be visible in onboarding, contracts, trading conditions, money flow and reporting, not only in the corporate chart.
- Acquirers underwrite legal entities, so each company generally needs its own merchant relationships and descriptors.
- A single scoped deployment works when obligations are compatible; separate deployments are cleaner where a supervisor expects segregation or data must stay in country.
- Client assignment between entities needs a documented rule and a logged reason, because undocumented moves are what examinations focus on.
Frequently Asked Questions
Can one trading platform serve a regulated and an offshore entity?
It can, provided entity is enforced across accounts, configuration, documents, payments and reporting, and provided neither regime requires physical separation or local hosting. Where a supervisor expects segregation, separate deployments are the safer build.
Do both entities need their own payment providers?
Usually yes, because acquirers and payment institutions underwrite a legal entity with its own ownership, licence position and risk profile. One integration covering two companies is rarely acceptable at underwriting.
Can clients be moved from one entity to another?
Only on a basis the firm can defend, with the reason recorded and the correct entity's agreement accepted afresh. Moving clients to obtain conditions their own market does not permit is a regulatory matter, not a configuration choice, and needs legal advice before it is attempted.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.