Multi-tenant, multi-connector
A single Ark instance serves many of your customer organisations (multi-tenant) and routes their requests across many backend providers (multi-connector). It is the shape Ark is built around — not a feature bolted on. This page explains the concept from the outside in: what the two words mean, why both matter at once, and what it unlocks. No code or internals — just the contract Ark holds.
The shape of the problem
A modern banking product is rarely one app calling one provider. It is:
- Many customers — different tenants you want to serve with one platform, each potentially under its own brand, with its own rules, regions, and permissions.
- Many providers — a core banking system, an identity-verification vendor, a comms gateway, a card processor, a fraud engine, a payments rail. Different customers may need different ones; the same customer may need several.
Without a layer in the middle, you end up with N × M integrations — every customer wired into every provider you want to support — and the resulting sprawl is what makes new products slow to ship and old vendors hard to replace.
Ark's answer
Ark is a single API in front of all of it. Calls come in tagged with which tenant they are for; Ark validates that the caller is allowed to act on that tenant, then routes each operation to the right backend connector for that tenant. The caller never picks a provider by name.
The N × M tangle collapses into N + M: every tenant connects once (to Ark), and every provider plugs in once (as a connector).
Two routing layers, in plain English
Ark resolves two questions on every request, in order:
- Whose tenant is this? Every call carries a tenant identity. Ark verifies that the caller (an authorised application of yours) is allowed to act on that tenant before anything else happens.
- Which connector handles this capability for that tenant? Every operation names a capability — open an account, verify a person, send a one-time code. Ark looks up the connector wired in for that capability under that tenant and dispatches the call.
You change a tenant's identity vendor by re-wiring step 2; the API the caller sees doesn't change.
The five words
| Word | What it means |
|---|---|
| Client | The top-level tenant — one of your customer organisations. |
| Brand | A sub-tenant inside a client. One client can run several brands with different rules and branding while sharing setup. |
| External application | An application of yours (or a partner's) that calls the Ark API on a client/brand's behalf. Authorised explicitly per client/brand. |
| Connector | A plug for a backend provider — core banking, identity, comms, etc. Connectors are interchangeable behind Ark's API. |
| Capability | A named operation Ark exposes (open account, verify identity, send notification). Capabilities are stable; the connector behind them isn't. |
These are the only words you need to reason about Ark from the outside.
What this enables
| Pattern | What it looks like |
|---|---|
| Vendor swap | Replace one provider with another for an existing tenant — the API the caller uses doesn't change. |
| White-label / brand split | One client, multiple brands; each brand can carry its own logo, rules, and even different connectors for the same capability. |
| Per-region differences | Different tenants in different jurisdictions use different identity, comms, and core banking providers — same API surface for the caller. |
| Bring-your-own | A tenant wants a specific vendor Ark doesn't currently integrate with — a new connector is added; existing tenants and connectors are unaffected. |
| Staged rollout | A new connector is wired in for one tenant before being offered to others, with no fork of the API. |
| Sandbox + production | Sandbox tenants point at sandbox connectors; production points at production. The caller's code is identical. |
What stays stable — the black-box contract
| Guarantee | Why it matters |
|---|---|
| One API shape | Capabilities don't change when providers do. You write to Ark, not to a vendor. |
| Tenant isolation | Each call is bound to exactly one tenant. Operating on the wrong tenant requires the caller to lie about identity to an external identity provider — not just Ark. |
| Authorisation at the edge | Caller-to-tenant authorisation is checked once, at the boundary, before any provider is touched. Providers are never reached by a request that fails this check. |
| Connectors are pluggable | Adding a provider doesn't change the API. Replacing one doesn't change it either. |
| Capabilities are named, not implied | The caller asks for what to do (open account); Ark decides who does it. This is the seam that lets the world behind Ark change without the world in front of Ark changing. |
A worked example
A partner application onboards a new customer for tenant Brand X:
If Brand X later switches identity provider, only step 3's connector changes. If a second brand on the same client uses a different identity provider, both work concurrently. The partner application sees the same call and the same response shape in every case.
Where this leaves you
- The API you build against is small, named, and stable.
- Tenant boundaries are enforced by Ark, not by your application.
- Providers are an implementation detail you can change without telling your callers.
Related
- B2B Authentication — how an external application identifies itself and proves it can act on a tenant.
- Administration External Applications API — how an application is authorised for a client/brand.
- Minimum Requirements — the hosting model the multi-tenant boundary is built on top of.