Multi-Entity Banking Platforms: What to Share and What to Separate

A common software platform can support several financial institutions, business units or brands. The value is straightforward: teams can reuse product development, integrations and operational tooling across more than one business.

The architecture still needs to answer a precise question for every operation: which entity owns this account, has authorised this action and is responsible for the resulting financial record?

This article proposes a practical way to design and evaluate those boundaries. The discussion applies both to groups running several entities and to technology providers serving independent institutions.

Separate the business model from the software model

Three terms need distinct definitions.

A brand is the identity presented to the customer. A legal entity is an organisation that can be a party to the customer or provider relationship. A tenant is the scope the software uses to organise configuration, access and resources.

Those concepts do not always map one to one. One entity may operate several brands. One customer may have relationships with several entities. A platform tenant may represent an institution, while separate entity identifiers organise its books and contracts.

Write the mapping down before choosing the deployment model. Include which entity provides each product, which account belongs to it and how a customer recognises that relationship in the application and statements.

This matters when a customer sees a consolidated dashboard. The ability to display several balances together does not, by itself, make funds interchangeable between the underlying accounts.

Build an ownership map for financial operations

Consider an illustrative platform serving Institution A and Institution B. They use the same software release and the same provider connector. Each has its own customer relationships, payment-provider account and operational policies.

The reusable parts are easy to identify. The ownership boundaries need equal attention:

Reusing a connector should not cause the platform to choose Institution A's provider account for Institution B's payment. Make the mapping between entity, product and provider account explicit, and preserve it on the operation for later investigation.

The same principle applies to price changes. A fee calculated under one entity's tariff should remain explainable after that tariff changes. Keep the applied rule or version with the operation instead of reconstructing its history from today's settings.

Treat a cross-entity transfer as a business operation

An internal transfer within one institution and a transfer between two institutions can look similar in a mobile application. Their processing requirements may differ substantially.

For the illustrative platform, model a transfer from an account at A to an account at B as two linked operations: an outgoing operation in A's books and an incoming operation in B's books. Specify how the movement is funded, which external settlement path is used where required, and when each side can make funds available.

Use a common transfer reference to connect the records. Keep each institution's status, fees and accounting consequences independently explainable. If one side fails, the workflow needs a defined resolution path.

A consolidated management report can combine those records for an authorised reader. It should preserve the contributing entity and currency, and distinguish reported totals from balances that a customer can actually spend.

Our article on ledger and reconciliation describes how internal records connect to external movements. In a multi-entity design, that relationship must remain clear for each set of books.

Make permissions specific to the institution

A job title alone is an incomplete permission. An operator may approve payments for Institution A and have read-only access to Institution B.

Bind each sensitive request to an authenticated person or service, an authorised entity scope, the requested action and the target record. The entity identifier sent by a browser is a selection to validate. OWASP explains this distinction in its Multi-Tenant Security Cheat Sheet.

For payment approvals, also evaluate the amount, product and any required separation of duties within the relevant institution. If a staff member changes entity while a payment screen is open, the submitted action must still be checked against the payment's actual owner.

Support access deserves its own workflow. Record who received access, for which institution, for what purpose and for how long. A support action should remain attributable to the staff member performing it, including when they are helping someone else.

Choose infrastructure from the operating requirements

Logical separation and physical deployment are related choices, but they are not identical. A separate database changes the data boundary; it does not automatically correct a routing error in a shared application.

Three common options illustrate the trade-offs:

Microsoft's multitenant storage guidance discusses these decisions in terms of isolation, scale and operational complexity. Use the institution's actual requirements for data location, maintenance and recovery to choose the boundary.

For a shared PostgreSQL database, row-level security can restrict record access. The runtime role matters: superusers and roles with BYPASSRLS bypass these policies; table owners normally do too. PostgreSQL documents those behaviours in Row Security Policies. Verify the deployed application role as part of the design review.

Follow the boundary through background processing

Many banking operations continue after the original HTTP request ends. A payment awaits a provider response, a statement is generated overnight or a reconciliation file arrives later.

For a statement job, preserve the authorised entity, account, reporting period and template version. At execution time, verify that the account belongs to that scope and select the correct institution's delivery configuration. The downloaded statement must retain the same ownership boundary.

For an incoming provider notification, identify the relevant provider account using authenticated integration context. Resolve the external reference within that account's scope. A matching reference string on its own should not select an unrelated institution's transaction.

Shared message processing also creates a capacity decision. One institution's bulk run can compete with another's routine work. Set workload limits and test realistic overlapping peaks. Microsoft describes the trade-offs between shared and dedicated messaging resources in its multitenant messaging guidance.

Test changes and recovery at entity level

Configuration is part of the financial behaviour of the platform. Test a fee change for Institution A while Institution B continues using its existing tariff. Repeat this with an approval limit and a provider route. Check new operations and those already in progress.

Then test recovery using an entity-specific incident. For example, a defective configuration caused incorrect fees at A while B processed normally. The recovery plan needs to explain which operations are affected, how corrections are recorded and how unaffected work continues.

Distinguish restoring technical data from reversing a financial operation. A database restored to an earlier point cannot undo a payment already executed by an external provider. The recovered system must account for external activity that occurred after the restore point before normal processing resumes.

For shared storage, test how the required records can be recovered or reconstructed without overwriting the other institution's later work. For dedicated storage, test the dependencies on shared services and provider records. Run the exercise far enough to reconcile the resulting financial state.

Ask for evidence of the boundaries

A practical evaluation can use two test institutions with deliberately similar account names and external reference formats. Give one operator different permissions in each, then run these checks:

1. Attempt to approve B's payment while holding approval rights only in A.
2. Change A's provider credentials and confirm B's route is unaffected.
3. Change A's tariff while an earlier A payment is still processing.
4. Generate statements for both institutions at the same time and inspect ownership, content and delivery.
5. Return a cross-entity transfer and trace the linked consequences in both sets of records.
6. Recover A's affected workflow and verify B's balances and operations remain correct.

For each result, retain the configuration, actor, entity, operation reference and expected financial outcome. These tests turn a broad claim of multi-entity support into a reviewable description of the architecture.