The problem with one login per entity
Picture a corporate services firm administering forty companies for a dozen clients, or a family office looking after five trusts, a foundation and a cluster of holding and property companies. Under the traditional model, each entity has its own account, its own online banking credentials and its own security token. Staff carry a drawer full of devices and a spreadsheet of passwords. Approvers have to log in and out repeatedly to approve a morning's payments.
The result is slow, error-prone and hard to control. Payments get made from the wrong entity because the wrong session was open. Leavers keep access to some entities because nobody remembered every login. Reporting means downloading statements one by one and stitching them together. And security suffers, because shared devices and written passwords are the opposite of good practice.
Multi-entity platforms are designed around a different idea: one identity per person, with access to as many entities as they are authorised for, and every entity kept separate in its balances, payments and records.
How a multi-entity platform is structured
Most platforms of this kind are organised in layers. At the top is the client relationship, which might be an administrator, a family office or a corporate group. Beneath it sit the individual entities, each a separate legal person or trust with its own onboarding, its own accounts and its own balances. Users sit alongside, each with a personal login, and are granted access to particular entities with particular rights.
The key principle is that an entity's money is never mixed with another's. Two companies administered by the same firm may appear side by side on a dashboard, but each has its own balances, its own transaction history and its own statements. A payment always debits one specific entity, and the platform should make it obvious which one.
Each entity must still be onboarded in its own right. Using one platform does not reduce the due diligence required for each company, trust or foundation, though it often makes it easier to reuse documents for shared directors or trustees across entities.
Entity switching
Entity switching is how a user moves between the entities they can access. Good design makes the current entity unmistakable: its name prominently displayed, perhaps with a distinct colour or label, so that a user preparing a payment always knows which entity will pay it.
Some platforms let users work on several entities at once, for example viewing a combined list of pending approvals across every entity and approving them in turn. This is efficient for approvers, provided each item clearly shows the entity it belongs to. Others require the user to switch into an entity before acting. Both approaches can work well. The test is whether a careful user could ever make a payment from the wrong entity without noticing. If the answer is yes, the design needs attention.
Search helps when the list of entities is long. Administrators with many entities will want to find an entity by name, client or reference without scrolling.
Permissions per entity
A multi-entity platform is only as good as its permission model. The same person may need very different rights on different entities. A family office accountant might prepare payments for every entity, approve for none, and view statements for all. A trustee's signatory might approve payments only for the trusts that trustee administers. A director of one holding company should see that company and nothing else.
Typical permission settings include:
- Entity access. Which entities the user can see at all.
- Role. For example viewer, payment creator, approver or administrator, set separately for each entity.
- Limits. Maximum amounts per payment or per day that the user can create or approve.
- Payee management. Whether the user can add or change payees, which is a sensitive right best given sparingly.
- FX rights. Whether the user can book currency conversions, and up to what size.
- Reporting and exports. Whether the user can download statements and data.
Permissions should mirror the legal authority behind each entity. If a company's board has authorised two named directors to approve payments jointly, the platform's approval rules for that company should require exactly that. Changes to permissions should themselves require approval and be recorded in the audit trail.
Approval workflows that scale
Approval rules are where multi-entity platforms earn their keep. Each entity can have its own workflow: one approver below a threshold, two above it, perhaps a specific approver for payments to new payees. The platform then routes each payment to the right people automatically.
For administrators, the ability to set a standard workflow and apply it to many entities saves considerable time, with exceptions configured where an entity's signing rules differ. For approvers, a single queue of pending items across every entity they act for is far more practical than visiting each entity in turn.
Dual authorisation should be enforced by the system, so that the person who created a payment cannot also approve it. Where an entity has only one authorised signatory, the workflow should reflect that honestly, and the organisation should consider whether a second check is needed.
Batch payments fit naturally into this model. A trust making distributions to several beneficiaries, or a company paying a run of supplier invoices, can submit a single batch for approval, with each line visible to the approvers.
Consolidated reporting
One of the main benefits of a single platform is reporting across entities. A treasurer can see total balances by currency across the group, the payments made by every entity in a period, or all FX conversions in a month, without assembling the data by hand.
Consolidated views must be read carefully. Totals across entities that belong to different owners, such as a trust and a beneficiary's personal company, are useful for operational planning but say nothing about who owns what. Every consolidated report should allow the user to drill down to entity level, and statements should always be available for each entity on its own.
Exports matter as much as screens. Accountants and auditors need data in consistent formats, by entity and by period, that can be loaded into accounting systems without manual reworking. Look for a platform that offers scheduled or on-demand exports and keeps the format stable over time.
Adding and removing entities
Groups change constantly. New companies are formed, trusts are settled, entities are sold or wound up. A platform should make it straightforward to add a new entity once it has been onboarded, to grant existing users access to it, and to apply a standard workflow.
Closing an entity should be just as orderly. Final balances are paid out, users' access is removed, and historical statements and audit records remain available for the period the organisation needs to keep them. Losing access to records when an entity closes is a common and avoidable problem.
Security considerations
A single login that opens many entities is convenient, and it also concentrates risk. If one user's credentials are compromised, every entity that user can reach is exposed. Strong authentication, ideally with a second factor on every login and every approval, is essential. Users should have the narrowest access their job requires, and access should be reviewed regularly, especially after staff changes.
The audit trail is a key security tool in a multi-entity setting. It should record which entity each action related to, so that a reviewer can see, for example, every change to payees across the whole platform in the last month. Our article on audit trails for payments sets out what a good trail captures.
Moving onto a multi-entity platform
Moving a group of entities onto a new platform works best as a planned project. Start with the entity map: every entity to be included, its legal name, its signatories and its approval rules as set by its board, trustees or council. That map becomes the configuration for the platform.
Next, onboard the entities. The provider will need documents for each, and grouping entities that share directors or trustees can save time, since identification of those individuals can be reused. Many groups start with a handful of the busiest entities, settle the workflows, and then add the rest in stages.
Then set up users. Each person receives their own login and is granted access entity by entity. This is a good moment to retire shared credentials and old security devices, and to confirm that nobody holds access they no longer need.
Finally, migrate payees carefully. Copying payee lists from old systems is convenient, but it can carry across errors or fraudulent changes. Re-verifying high-value and frequently paid payees before the first payments go out is worth the effort. Scheduled payments, such as rent or regular distributions, should be recreated and approved on the new platform before the old arrangements are cancelled.
What to check when choosing
When comparing platforms, a short checklist keeps the discussion practical:
- Each entity can have its own approval rules, limits and payees.
- A user can hold different roles on different entities.
- The current entity is always clear when preparing or approving a payment.
- Consolidated views are available, with drill-down to entity level.
- Statements and data can be exported by entity in standard formats.
- A full audit trail covers user, permission and payee changes as well as payments.
- The provider understands trusts, foundations and companies, and onboards each of them properly.
- There is a named contact who knows the structure and can answer questions about it.
It is worth asking for a demonstration using a structure similar to your own, with several entities and users holding different roles, before committing.
General information only
This article is general information about multi-entity payment platforms. It is not legal, accounting or regulatory advice, and each organisation should design its permissions and approval rules around its own legal authorities and risks.
CCYFX Online gives administrators and family offices multi-entity access with user roles, limits, dual authorisation, scheduled payments and full reporting. See the platform page for details.
