Technical architecture

For the banking workflow and responsibilities, start with Platform architecture. This technical companion covers the system connections, settlement services and request examples.

Who this is for

Bank architects and systems integrators who need to place Quant Flow Platform in their estate. It covers the parties that call the platform, the capabilities behind the gateway, where the book of record sits, and the path of a token operation. It does not cover hosting. The platform runs either Quant-hosted or in your own infrastructure, with the same API in both. See Deployment model.

The parties

The Management Panel uses the same API documented here. Build client integrations against the published API Reference; do not depend on private Management Panel requests.

The book of record

Your core banking system remains the book of record for customer deposits. The platform records token contracts, customers, accounts and token operations, and reads balances from the token contract. It does not replace your ledger. Your bank decides when to issue (mint) or redeem (burn) tokens, based on deposits it has already booked, and reconciles the platform's outcomes against its own records.

In the standard workflow, your KYC/AML checks run in your own systems before they call the platform. A connector that calls your screening service from inside the platform, before an operation is signed, is not available today.

Your adapter must implement the core-banking connection. The public API contains no core-banking connector or coordinated cash-leg endpoint.

Quant Flow reference architecture

How bank applications reach Quant Flow, and how Quant Flow orchestrates tokenisation across DLT networks and existing bank infrastructure.

Integration boundaries

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Core["Your core banking ledger"] --> Adapter["Your integration adapter"]
    Adapter --> Gateway["Quant Flow API gateway"]
    Panel["Management Panel / approvers"] --> Gateway
    Gateway --> Policy["Configured policy and approvals"]
    Policy --> Engine["Token settlement"]
    Engine --> Custody["External custody: signing keys"]
    Custody --> Engine
    Engine --> Network["Permissioned token network"]
    Network --> Engine
    Engine --> Events["Signed webhooks"]
    Events --> Adapter
    Adapter --> Core

Your adapter connects the cash ledger to token outcomes. Policy applies only when enabled; external custody retains the blockchain keys. Quant Flow does not post the cash leg.

Token operations · Policies · Webhooks

Capabilities behind the gateway

Requests go to your assigned gateway with the documented API-Version header. Protected operations carry a bearer token identifying the principal (sub) and organisation (tenant_id). Tenant-scoped operations enforce that organisation; shared catalogues and bootstrap authentication have their own access rules. The published host is https://api.qfp.quantnetwork.net; confirm your environment's host and deployed authentication controls during onboarding. See Authentication.

Settlement services behind the API

Some platform services do their work behind Treasury. Customers need to understand their responsibilities without connecting to their private interfaces.

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Bank["Bank adapter and cash ledger"] --> Gateway["Gateway and Identity"]
    People["Bank operators and approvers"] --> Gateway
    Gateway --> Treasury["Treasury: contracts, accounts, token operations"]
    Gateway --> Scripts["PayScript and execution engine"]
    Scripts --> Treasury
    Treasury --> Policy["Policy and approvals when enabled"]
    Policy --> Treasury
    Treasury --> Prepare["Overledger: prepare"]
    Prepare --> Sign["Authorise and configured custody: sign"]
    Sign --> Broadcast["Overledger: broadcast"]
    Broadcast --> Chain["Token contracts on permissioned network"]
    Chain --> Tracker["Tracker: observe outcome"]
    Tracker --> Treasury
    Treasury --> Notify["Notifications: signed webhooks"]
    Notify --> Bank
    Gateway --> Audit["Audit and issuer reporting"]

The diagram explains responsibilities, not extra customer endpoints. The deployment determines custody mode, enabled controls and network connectivity. Bank cash postings remain in your own integration.

The path of a token operation

A token operation is one business instruction: mint, burn, transfer, lock, release or cancel. The API calls it a transaction. It is accepted first and settles later, without further calls from you.

CONFIRMED, FAILED and CANCELLED are terminal. Balances reflect an operation only once it settles. Operations and their lifecycle gives every state and failure code.

Operations settle on a private, permissioned, EVM-compatible network with immediate, deterministic finality: once a block is finalised it is not reversed. See Supported networks.
Policy is disabled in the shipped settlement configuration. When enabled, the default judged types are MINT, BURN, TRANSFER and LOCK. Confirm the environment's policy configuration and approval controls before go-live; the sample below illustrates the policy-enabled path.

Separation of duties

The design separates the party that proposes a money movement from the people who approve it. Bank systems submit operations. Policies decide which operations need approval. Approvers act through the approvals API with their own user token, and each approval action is recorded. Roles are built from a permission catalogue, so you can give a machine client token-operation permissions without approval permissions. See Policy, approvals and audit and Identities and entitlements.

Worked example

A mint submission, an intermediate read and a failed settlement response. The sample follows the policy-enabled path; it is illustrative contract data, not a live test result.

Submit:

POST /api/transactions HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0
Content-Type: application/json
Idempotency-Key: 3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13

{
  "txType": "MINT",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "amount": "10.50"
}

Accepted:

HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "transactionId": "3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13",
  "txType": "MINT",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "counterpartyRef": null,
  "amount": "10.50",
  "params": {},
  "state": "POLICY_PENDING",
  "createdAt": "2026-08-06T09:29:10.285Z",
  "updatedAt": "2026-08-06T09:29:10.285Z"
}

Read back while in flight with GET /api/transactions/{transactionId}:

{
  "transactionId": "3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13",
  "txType": "MINT",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "counterpartyRef": null,
  "amount": "10.50",
  "params": {},
  "state": "VALIDATED",
  "createdAt": "2026-08-06T09:29:10.285Z",
  "updatedAt": "2026-08-06T09:29:12.041Z"
}

A failed settlement carries the classification in failureCode and the specific reason in reasonCode:

{
  "transactionId": "3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13",
  "txType": "MINT",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "counterpartyRef": null,
  "amount": "10.50",
  "params": {},
  "state": "FAILED",
  "failureCode": "CHAIN_FAILED",
  "reasonCode": "EXECUTION_REVERTED",
  "txHash": "0x4a1b8c7d2e5f309a6b1c4d7e8f0a2b3c5d6e7f8091a2b3c4d5e6f7089a1b2c3d",
  "blockNumber": 18446801,
  "createdAt": "2026-08-06T09:29:10.285Z",
  "updatedAt": "2026-08-06T09:33:12.550Z"
}

View in API Reference

• Submit a token operation · POST
• Get one token operation · GET

Errors and edge cases

• Accepted is not settled. A 202 from POST /api/transactions confirms acceptance only. Do not post to your ledger on a 202. Wait for CONFIRMED.
• Balances are not checked at submission. An operation for more than the account holds is accepted and then fails during settlement.
• An operation can wait for approval until the request expires. Each policy can set a time-to-live for its approval requests, in hours, days, weeks, months or years. When it elapses, the request and its pending tasks move to EXPIRED. A request from a policy with no time-to-live stays PENDING until someone acts on it.
• An asset needs an ACTIVE contract before accounts can be registered or operations raised against it. A missing contract is a 404 when registering an account and a 400 when submitting an operation.
• Accounts are provisioned asynchronously. POST /api/accounts returns 202 with the account PENDING. The wallet address appears when provisioning completes.

API Reference

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

Related pages

• Operations and their lifecycle
• Balances
• Policy, approvals and audit
• Choose your integration model
• Webhooks
• Limitations