Production readiness

What production readiness means

Before serving customers, the bank needs evidence that its selected workflows work in the assigned environment and that teams know how to operate and recover them. A successful login or one completed token issue establishes only that particular test.

The bank owns customer screening, cash postings, its systems connection and reconciliation. Quant Flow supplies the documented token workflows, enabled policy controls and outcome notifications. Quant and the deployment operator establish the environment and signing configuration.

Product, operations, security and technology owners should review the test evidence, operating arrangements and unresolved exceptions together before authorising customer traffic. The checks below support that decision; they do not replace environment-specific testing.

1. Record the environment agreement

Before enabling customer traffic, record the assigned gateway and identity-provider token URLs, tenant identifier, API version, assets, network and custody arrangement. Identify the bank's integration and operational owners and the operator's escalation route. Confirm connectivity, gateway authentication, request budgets and the required user and machine-client permissions.

Keep support hours, maintenance notice, recovery objectives, backup ownership, data location and retention in the deployment operating agreement. The HTTP contract does not set these commercial or infrastructure commitments. See Get access and Service characteristics.

2. Verify assets and accounts

Read the contract registrations and ensure each intended asset is ACTIVE. Confirm signing-key registration, custody connectivity and on-chain authority with the operator. An ACTIVE customer account alone does not prove that minting or burning can be signed.

Register a test customer and account through Create a customer and an account. Read the account until provisioning has an outcome. Retain its bank reference, asset, wallet address and any failure reason. The customer/account records do not perform KYC or move the cash deposit.

3. Exercise the bank adapter

Test	Evidence to retain
Mint, transfer and burn	Request, original idempotency key, operation ID, final state, ledger evidence and corresponding bank postings.
Locks, release and cancellation, when used	Stored lock ID, beneficiary, remaining locked amount and final operation outcomes.
Approval and rejection, when enabled	Configured policy version, separate authorised approver identities, decision and resulting operation state.
Lost response and repeated submission	Same intent and key produce one operation; business posting remains duplicate-safe.
Provisioning refusal, insufficient funds and settlement failure	The adapter distinguishes request acceptance from later failure and routes uncertain outcomes to investigation.
Signed events and receiver outage	Signature checks, durable receipt, duplicate-safe processing, replay and successful state-read recovery.
Token expiry and denied access	Refresh/re-authentication handling and evidence that configured permissions are enforced.
Reconciliation	Confirmed movement and balances match the bank records; breaks have a named owner.

Use controlled non-production resources. Do not advertise a workflow as tested because its request schema exists. Policies and authentication marked planned in a service reference require explicit deployed-enforcement verification.

4. Sign off optional capabilities separately

For PayScript, obtain the approved action names, arguments and execution identity. Test each selected trigger, version handover and the pause/resume process. Agree how the operator will provide run-outcome evidence: an accepted execution request is not proof that a payment settled.

For policy authoring and approval groups, test the assigned administrator permissions and configured enforcement with independent submitter and approver identities. A saved policy is not a dry run. Follow Write and run an automation, Author and test a policy and Limitations.

5. Agree release and recovery ownership

Record the tested application/API versions, test results, open exceptions, escalation owners and the authority to enable submissions. Exercise Maintenance and recovery before production. Do not sign off unresolved signing, access or reconciliation failures as acceptable merely because other requests pass.

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Config["Confirm environment and owners"] --> Assets["Verify asset, custody and accounts"]
    Assets --> Test["Exercise selected workflows and failure paths"]
    Test --> Evidence["Reconcile and review evidence"]
    Evidence --> Ready{"Required checks passed?"}
    Ready -->|Yes| Enable["Authorised enablement in bank adapter"]
    Ready -->|No| Resolve["Resolve gaps and repeat affected checks"]
    Resolve --> Test

Worked example

Illustrative request and response from the published contract. Replace identifiers and credentials with those assigned to your environment. This example is not a live test result.

GET /api/accounts/ACC-0001 HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0

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

{
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "assetId": "GBP",
  "status": "ACTIVE",
  "walletAddress": "0x4E55aD154FFfE514D7dEF1658dEbe593907121ae",
  "createdAt": "2026-08-03T09:29:10.285Z",
  "updatedAt": "2026-08-03T09:29:14.911Z"
}

View in API Reference

Get an account · GET

An ACTIVE account with a wallet address confirms provisioning in this example. It does not certify custody signing authority, policy enforcement or cash backing; verify those separately.

API Reference

Open an endpoint for request fields, response schemas, examples and documented errors.

Operation	Method
List contracts	`GET`
Get an account	`GET`
Get one token operation	`GET`
Send one signed test delivery now, and return the outcome	`POST`
List the operations that failed or never got an answer	`GET`