Multi-tenancy in financial SaaS platforms

What is multi-tenancy and why does it matter in Fintech?

Multi-tenancy is when a single instance of your application serves multiple clients (tenants), each with their own completely isolated data. In a financial platform, this isn't optional - it's critical.

Imagine a platform where different investment funds manage their portfolios. Fund A should never see Fund B's data, not even by accident. A mistake here isn't just a bug - it's a compliance violation that can cost you your license.

The three main approaches

1. Separate database per tenant

Each client has their own database. It's the most secure approach but also the most expensive and difficult to maintain.

Advantages:

• Total isolation
• Easy to comply with data regulations
• Backups and restoration per client

Disadvantages:

• Expensive infrastructure
• Schema migrations are a nightmare
• Hard to scale to many tenants

2. Separate schema per tenant

A single database, but each client has their own schema (set of tables).

Advantages:

• Good balance between isolation and cost
• Easier to maintain than separate databases

Disadvantages:

• Migrations are still complex
• Schema limits in some databases

3. Shared tables with tenant_id

All clients share the same tables, but each row has a tenant identifier.

Advantages:

• More economical
• Simple migrations
• Scales well to thousands of tenants

Disadvantages:

• A bug can expose other clients' data
• Requires extreme discipline in queries

Row Level Security: your safety net

In platforms like FundLayer, we use the third approach (shared tables) but with an additional security layer: Row Level Security (RLS).

RLS is a feature in databases like PostgreSQL that automatically applies filters at the database level. No matter what query you run - the database always filters by the current tenant.

How it works in practice

1. The user authenticates and their session includes the tenant_id
2. The database knows that tenant_id from the session context
3. Each table has a policy that says: "only show rows where tenant_id = current tenant"
4. Even if a developer forgets the filter in their query, RLS applies it automatically

Why this is revolutionary

Without RLS, you depend on every developer, in every query, in every endpoint, remembering to filter by tenant. It's a matter of time until someone forgets.

With RLS, the filter is in the database. It's impossible to skip it accidentally. You can do SELECT * FROM transactions and you'll only see your tenant's.

Important architecture decisions

Tenant context

How does your application know which tenant is making the request? There are several ways:

• Subdomain: funda.platform.com vs fundb.platform.com
• HTTP Header: A header like X-Tenant-ID in each request
• JWT Token: The tenant_id comes inside the authentication token

In financial applications, I recommend the JWT token. It's more secure because the tenant is cryptographically signed - it cannot be manipulated by the client.

Shared data vs tenant data

Not everything should be isolated. Some data is global:

• Financial product catalog
• System configurations
• Platform admin users

Others are strictly per tenant:

• Transactions
• Fund clients
• Documents and contracts
• Reports

Designing this separation well from the start saves you months of refactoring later.

Auditing and compliance

In Fintech, every action must be logged. Your audit system must also be multi-tenant:

• Who did what, when, from where
• Changes to sensitive data
• Access to client information

This isn't just best practice - it's a regulatory requirement in most jurisdictions.

Common mistakes I've seen

1. Trusting only application code

"We already filter in the backend" isn't enough. A single poorly written endpoint exposes everything. RLS at the database level is your backup.

2. Not testing isolation

You must have automated tests that try to access other tenants' data. If they ever pass, you have a serious problem.

3. Forgetting background jobs

Your API might be perfect, but what about cronjobs, workers, and background processes? They also need tenant context.

4. Logs with sensitive data

Be careful what you log. A log that includes data from multiple tenants mixed together is a security risk.

Conclusion

Multi-tenancy in Fintech isn't just a technical decision - it's a business and compliance decision. Doing it right from the start allows you to scale to hundreds of clients without rewriting your platform.

The combination of shared tables + Row Level Security + good auditing practices is the sweet spot for most financial SaaS platforms. It's economical, secure, and lets you sleep peacefully knowing a bug won't expose other clients' data.