One Platform. Fifty Banks. Zero Chaos.

The first four issues were about specific
systems - retries, scheduling, APIs, failure costs.

This week we zoom out to the architectural
challenge underneath all of them:

How do you build one platform that serves
50 banks - each with different rules,
different risk appetites, and different
definitions of "correct"?

This is the multi-tenant problem. And it's
one of the most underwritten topics in
FinTech product.

- Gaurav

Every FinTech platform makes the same
promise to its bank customers:

"You get a fully configured solution
tailored to your needs."

It's a great sales pitch. It's an
engineering nightmare.

Because behind that promise is a
platform that has to serve Bank A
and Bank B simultaneously - on the
same infrastructure, with the same
codebase - while making each of them
feel like the platform was built
specifically for them.

That's the multi-tenant problem.

And it starts simple. One bank.
One configuration. Everything works.

Then the second bank signs. They
want different transaction limits.
A different fraud threshold. A
different cut-off window for ACH.
A different format for their
settlement reports.

And suddenly the platform that worked
perfectly for one bank has to make
decisions it was never designed to make.

Bank A needs this behaviour?
Add a condition. Bank B needs
something different? Add another.

It works. Until it doesn't.

Six months later the codebase is
riddled with bank-specific logic.
Every new feature has to account
for seventeen different conditions.
Every bug fix risks breaking a
configuration that was quietly
depending on the broken behaviour.

This is configuration debt. It
accumulates silently and compounds
quickly.

The platforms that scale to 50 banks
don't solve multi-tenancy with
if-statements. They solve it with
architecture.

The right approach separates three
things that most platforms accidentally
combine:

Core behaviour - what the platform
does for every bank, always, without
exception. This is the foundation.
It never changes per tenant.

Configurable behaviour - what the
platform does differently based on
each bank's settings. Transaction
limits. Fraud thresholds. Notification
preferences. Cut-off windows. These
live in configuration - not in code.

Custom behaviour - the rare cases
where a bank genuinely needs something
no other bank needs. This is handled
through extension points - defined
interfaces that allow customisation
without touching the core.

When these three layers are clearly
separated, adding a new bank becomes
a configuration exercise - not a
development project.

When they're tangled together - every
new bank is a potential regression
for every existing bank.

Multi-tenancy isn't just about
configuration. It's about isolation.

When 50 banks share the same
infrastructure, one bank's behaviour
cannot affect another's.

This sounds obvious. It's surprisingly
hard to guarantee.

A bank that generates unusually high
transaction volume shouldn't degrade
performance for other banks. A bank
that triggers a fraud rule shouldn't
leak signals into another bank's
fraud model. A bank that misconfigures
a setting shouldn't cause a failure
in a shared processing queue.

Logical isolation - through
configuration, access controls,
and data boundaries - is what
makes shared infrastructure safe
for regulated financial institutions.

Without it, you don't have a
multi-tenant platform. You have
a shared system with shared risk.

Multi-tenancy in FinTech has a
compliance layer that most
architecture discussions ignore.

Each bank on the platform operates
under its own regulatory obligations.
Its own state licensing. Its own
risk policies. Its own audit
requirements.

The platform has to honour all
of these simultaneously - without
letting one bank's compliance
posture affect another's.

This means every configurable
behaviour needs guardrails. A
bank can't configure its way
out of a NACHA requirement. It
can't set a fraud threshold so
low it creates regulatory exposure
for the platform.

Configuration flexibility and
compliance boundaries have to
coexist. The platform - not the
bank - is responsible for
knowing where the line is.

Multi-tenancy is usually framed
as an engineering problem.

It's actually a product problem
that engineering builds.

The decisions that matter - where
to draw the line between core and
configurable, how to enforce
compliance boundaries, how to
prevent one tenant's behaviour
from affecting another's - are
product decisions.

Engineers can implement any
architecture. Only a PM who
understands the business, the
regulation, and the tenant
relationships can define which
architecture is right.

If you own a platform product -
and you haven't explicitly defined
what is core, what is configurable,
and what is custom - your platform
is making those decisions implicitly.

And implicit decisions accumulate
into the kind of technical debt
that takes years to unwind.

Interagency Guidance on Third-Party
Relationships: Risk Management

Jointly issued by the Fed, FDIC, and OCC
in June 2023 — the authoritative regulatory
framework for how banks should manage
platform and service provider relationships.

If you build a platform that banks operate
on, this document describes exactly what
your bank customers' regulators expect
from you — including isolation, oversight,
and configuration risk across tenants.

fdic.gov/banker-resource-center/
third-party-relationships

- Gaurav Nikumbh
Senior PM · Payments & Banking Infrastructure
Founder, TechVenture360

What's the hardest multi-tenant
problem you've encountered -
as a builder or a customer?

Hit reply. The most interesting
answers become future issues.