Deployment model

Who this is for

Bank architects, infrastructure teams and risk functions deciding where Quant Flow Platform should run. This page covers the two deployment models, how banks are isolated from one another, who operates each layer, connectivity, data residency and releases. It does not cover individual security controls. See Security and key management.

Two deployment models

The platform supports Quant-hosted and client-hosted models. Confirm the installed release, enabled features and control configuration for your environment. The infrastructure responsibilities differ as shown below; the approved deployment design determines their implementation.

Use the published API contract for both models and confirm the assigned gateway, trusted issuer, claims and enabled workflows during onboarding.

Isolation between banks

Confirm whether your bank has a dedicated deployment/database and record the isolation boundary in the approved hosting design. Do not infer physical isolation from a tenant-scoped API response.

Inside a deployment, tenant-scoped business operations use the organisation in the access token. Any tenant ID in a path must match that identity. Shared resources and user-by-ID lookup have distinct rules; see Authentication.

Shared responsibility

Controls built into the application are the same in every deployment. These include request validation, idempotency, webhook signing, structured logging and the append-only audit history of every change to persistent data.

In the client-hosted model, the bank operates the layers around the application:

Connectivity

External traffic reaches the platform over HTTPS. TLS 1.2 is the minimum and TLS 1.3 is preferred.

• Quant-hosted. The API can be reached over a private link from the bank's own cloud network, so traffic does not cross the public internet. Agree gateway exposure, private connectivity, firewall rules and any IP allow-listing with the deployment team. An API server URL does not specify the network access arrangement.
• Client-hosted. The bank's systems reach the platform over the bank's own private network paths, such as a site-to-site VPN, a dedicated interconnect or a private link. The platform's services, databases and message broker run on the bank's private network.

Inventory outbound dependencies with the deployment team, including identity keys, custody/HSM services, ledger nodes, webhook receivers and any enabled institution-identity verification service. The public endpoint list is not a complete network allow-list.

Data residency

The platform holds the operational data tokenisation needs: accounts and their references, token definitions, scripts and automations with their execution history, policies and decisions, webhook subscriptions and delivery events, signing requests (the transaction and its status, never a key) and the record of each ledger transaction. Data written to the ledger is limited to what the token contract requires.

• Quant-hosted. Data resides in Quant's hosting region under Quant's retention policy. Agree the hosting region and data-location requirements before provisioning the environment.
• Client-hosted. The bank hosts the databases, so it controls residency, retention, backup encryption and the handling of any data-subject or regulatory request.

Ledger nodes and custody

Tokens are issued on a private, permissioned ledger network that only the platform's own nodes join. See Supported networks.

• Quant-hosted. Quant operates the network's nodes and the custody integration.
• Client-hosted. Where the ledger nodes run is agreed with the bank as part of the deployment design. The bank's custody provider holds the signing keys in the bank's own workspace.

Document who operates the ledger nodes and how the bank connects to the selected network in the deployment operating model.

Releases and change

Obtain the approved release artefacts, source/version identity, release notes and available build/test/signature evidence for each upgrade. Agree the delivery cadence and security-patch process with the release owner; the API contract does not establish these assurances.

• Quant-hosted. Quant deploys releases. Agree the release calendar, notice period, rollback responsibilities and acceptance testing with your platform contact.
• Client-hosted. The bank deploys each release into its own non-production environment first and promotes it to production under its own change management.

A change that breaks clients is released as a new major API version. See API versioning.

Worked example

The same request in both models. Only the host and the issuer of the access token differ.

Quant-hosted:

GET /api/accounts/ACC-0001/balances HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token issued by the Quant-operated identity provider>
API-Version: 1.0.0

Client-hosted:

GET /api/accounts/ACC-0001/balances HTTP/1.1
Host: <your gateway host>
Authorization: Bearer <access token issued by your identity provider>
API-Version: 1.0.0

The response is the same in both:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "assetId": "GBP",
  "total": "1250.00",
  "available": "1210.00",
  "locked": "40.00",
  "asOf": "2026-08-13T11:58:04.114Z"
}

View in API Reference

• Get an account's balances · GET

Errors and edge cases

• A token from another deployment is rejected. Tokens are validated for signature, issuer and expiry on every request, and a missing, expired or malformed token returns 401.
• Client-hosted infrastructure is the bank's to size and operate. Availability of the gateway, identity provider, database, secret store and custody connection sits with the bank in that model.
• Recovery after a failover. The operational database records intent and status. Value is recorded on the ledger. After a failover, operations in flight are reconciled against the ledger. See Reconcile against your core banking.

API Reference

Open an endpoint for request fields, response examples and the interactive API console.

Related pages

• Platform architecture
• Supported networks
• Security and key management
• Service characteristics
• Choose your integration model