Master Account, Sub-Accounts: How Multi-Tenant Payment Products Actually Work

If you’ve built or worked on a SaaS product, “multi-tenant” is a familiar term. One codebase, one database, many customers, each scoped off from the others by a tenant_id column and some row-level security. Payments infrastructure needs the same conceptual model, but the isolation requirements are stricter, because the thing being isolated isn’t a customer’s data. It’s their money. A multi-tenant payment infrastructure that gets this wrong doesn’t produce a data leak; it produces a reconciliation nightmare, or worse, one tenant’s funds becoming indistinguishable from another’s.

In this guide, we’ll break down why isolation in payments has to happen at a different layer than it does in typical SaaS multi-tenancy, how the master account/sub-account architecture actually works technically, how isolated customer balances get enforced at the ledger level rather than the application layer, what a sub-account management API looks like in practice, and why building this yourself is usually the wrong engineering investment and how WeWire’s own infrastructure is built to solve it.

Multi-Tenant SaaS vs. Multi-Tenant Payments: Why Isolation Is Different

In a typical multi-tenant SaaS product, isolation is mostly a query-layer concern: every read and write gets scoped by tenant, and as long as your application logic is correct, tenants stay separated. If a bug leaks that scoping, the failure mode is usually visibility: Tenant A sees Tenant B’s data.

In payments, that same class of bug has a much worse failure mode: Tenant A’s balance calculation includes Tenant B’s transactions, and now two customers’ money is entangled in a way that isn’t just a permissions fix. It’s a financial reconciliation problem, potentially a regulatory one. This is why multi-tenant payment infrastructure can’t treat isolation as an application-layer nicety. It has to be structural, enforced at the ledger itself, not just filtered at the API response.

The Master Account, Sub-Accounts Architecture

The pattern that solves this is a two-level model. A platform, a marketplace, a neobank, or a payroll product opens one master account sub-accounts relationship with a licensed infrastructure provider. That master account is the actual legal and contractual relationship: it’s what the provider’s compliance team underwrites, what KYB is performed against, and what the platform is billed through.

Underneath that master account, each of the platform’s own end customers gets a sub-account: an individually addressable ledger entity with its own identity, balance, permission scope, and KYC status. 

Critically, a sub-account isn’t a row in the platform’s own database tagged with a tenant ID. It’s a first-class object in the infrastructure provider’s ledger, with the same rigor applied to it as to any standalone account. That’s what makes the master account sub-accounts pattern fundamentally different from bolting multi-tenancy onto a single-ledger system after the fact.

Enforcing Isolated Customer Balances at the Ledger Level

This is the part worth being precise about, because it’s where a lot of homegrown implementations quietly fail. Isolated customer balances aren’t achieved by filtering a shared balance table by customer ID at query time. That’s the SaaS pattern, and it breaks under concurrent writes, partial failures, and audits. 

A properly built system enforces isolation through double-entry accounting at the sub-account level: every transaction posts as a balanced pair of entries against specific sub-account ledgers, so a sub-account’s balance is always the deterministic sum of its own entries, never a derived or shared figure.

That structure is what makes an audit trail actually trustworthy. If a regulator or an auditor asks a platform to prove exactly what’s in Customer X’s balance and how it got there, the answer needs to be a query against that customer’s own ledger history, not an explanation of the application logic that’s supposed to keep balances separated. Permission scoping follows the same principle: each sub-account can carry its own limits, its own allowed transaction types, and its own KYC/KYB tier, enforced by the infrastructure layer itself rather than by the platform remembering to check.

The Sub-Account Management API in Practice

Concretely, a sub-account management API exposes a small set of operations that map directly onto this model: create a sub-account (typically triggered the moment an end user completes onboarding), assign its permission scope and limits, query its balance and transaction history, and trigger a transfer in or out. Every state change. A deposit landing, a payout completing, a balance updating fires a webhook, so the platform’s own systems stay synchronized without polling.

This is also where a well-designed sub-account management API distinguishes itself from a thinner wrapper: real support for provisioning thousands of sub-accounts programmatically as users onboard at scale, rather than an API that was clearly designed for a handful of manually created accounts and starts straining under load.

Why This Beats Building Ledgering In-House

For engineering teams weighing whether to build this themselves, the numbers are stark. Building a general ledger system in-house typically requires between $2 million and $10 million in initial investment, against $50,000 to $200,000 for a ledger-as-a-service integration, with the financial break-even point for building your own only arriving somewhere around 5 to 10 million annual transactions, according to Finantrix’s comparison of ledger-as-a-service providers versus building in-house. 

Separate industry research puts a bare general ledger build specifically at $140,000 to $400,000 and 8 to 15 months of development time, against roughly a two-week integration timeline for an embedded ledger API, per Open Ledger’s build-versus-buy cost analysis. Beyond the raw cost, in-house builds carry ongoing compliance engineering burden that a licensed provider absorbs by default, SOC 2 and equivalent controls, regulatory reporting, and audit-readiness that would otherwise need to be built and maintained indefinitely.

Unless ledgering itself is the core differentiator of the product, that engineering investment is almost always better spent on the parts of the platform customers actually interact with.

WeWire’s Multi-Tenant Payment Infrastructure

WeWire’s own architecture is built around exactly this model, for platforms that don’t want to make the ledger-building decision at all. The sub-account management API lets a platform provision isolated customer balances for every end user under its own master account, with permission scoping, configurable KYC/KYB tiers, and a webhook-driven reconciliation feed built in from the start, running on infrastructure already licensed as a FINTRAC-registered Money Services Business and PSP in Canada, with a Global Business License and Treasury Activities authorization in Mauritius.

For teams thinking about API-first infrastructure more broadly, WeWire’s APIs are reshaping who counts as a competitor. Backed by over $3 billion in transaction volume processed across more than 3,000 registered businesses, account registrations spanning 80+ countries, and payment reach into 100+ countries total, WeWire’s multi-tenant payment infrastructure gives engineering teams the same ledger-level isolation they’d have to build from scratch without the 8-to-15-month timeline or the seven-figure price tag.

Conclusion

Multi-tenancy in payments looks like a familiar engineering problem right up until the isolation requirements reveal themselves to be structural rather than architectural convenience. At that point, the difference between a query-layer workaround and true isolated customer balances is the difference between a system that survives an audit and one that doesn’t. 

The master account sub-accounts pattern, backed by a real sub-account management API, is the model that’s actually built to hold up under that scrutiny, which is exactly why it’s worth evaluating as infrastructure to build on rather than a system to build yourself.