Daily operations and monitoring

Daily review for operations teams

Start with work that has no confirmed outcome, accounts that are not ready, approvals waiting for a decision, notifications that were not delivered and differences between the bank and token records. Assign a named person to each exception and agree when it should be escalated.

A delayed instruction may still settle. Check its current outcome before anyone repeats a payment or changes a cash posting. The bank's technology team supplies the tracking and notification checks described below; operations owns the investigation and reconciliation process.

What your team monitors

Use the bank adapter's durable instruction journal as the starting point. Track business reference, idempotency key, transaction ID, account, asset, amount, last observed state and observation time. Quant Flow exposes resource and outcome reads; your team defines alert thresholds and escalation ownership for its deployment.

A monitoring interval or maximum age is an operating choice, not a universal timeout promised by the API. Avoid polling every account aggressively; agree capacity and use events to prompt reads.

1. Review unresolved instructions

Read operations by their stored transaction IDs. A successful HTTP response does not mean an operation is CONFIRMED. Review instructions that stop changing, including POLICY_PENDING, AWAITING_APPROVAL, HELD and submitted operations whose settlement is uncertain. Read outstanding breaks and assign investigation ownership in your bank's incident system.

The public API can read breaks but cannot resolve or update them. A policy deadline is not currently enforced; an old POLICY_PENDING instruction needs operator investigation. Do not submit a replacement with a new key solely because a threshold has elapsed. See Handle failures.

2. Check provisioning and approvals

Review PENDING and FAILED accounts and capture failureReason. A failed account registration may be retried only through the documented registration behavior after its cause is corrected; use a new intent/key where required. Do not change identifiers to conceal an unresolved provisioning problem.

Review approval requests and the authorised user's task inbox. An approver decides with their own identity. When an approver leaves, use documented reassignment where permitted and check policies before changing group membership. A deactivated group can cause policy evaluation to fail.

3. Check event delivery

Read webhook destinations and delivery history. Investigate SUSPENDED registrations, failed deliveries, receiver latency and events stored but not yet processed by your business worker. Repair the receiver, verify the signature path, send a test delivery and reactivate the destination through its documented update operation when appropriate.

Replay eligible stored deliveries after recovery. A new subscription does not backfill events that had no delivery for that destination. Keep processing idempotent on Webhook-Event-Id; repeated delivery is not a new payment. Use resource reads and the instruction journal for missing-event recovery.

4. Reconcile and escalate

Compare settled balances and confirmed token movements with the bank's booked deposit and payment records. Store each difference with its account, asset, operation IDs and ledger evidence. Keep activity-log evidence separate from proof of settlement. Dashboard and reserve placeholder figures are not authoritative reconciliation inputs.

An escalation packet should include environment, API version, sanitised request/status, business and operation IDs, timestamps, failure code and ledger evidence when present. Exclude access tokens, shared secrets and private keys. Use the secure channel agreed with your Quant contact.

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Journal["Instruction journal and delivery history"] --> Read["Read current resource state"]
    Read --> Check{"Outcome and bank records agree?"}
    Check -->|Yes| Record["Record evidence and continue monitoring"]
    Check -->|No| Investigate["Assign exception owner"]
    Investigate --> Recover["Repair, obtain operator evidence and reconcile"]
    Recover --> Read

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/transactions/3f7c1a90-5d2e-4b08-9a41-6c2b8e5d7f13 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

{
  "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

• Get one token operation · GET

The failed MINT includes CHAIN_FAILED, a transaction hash and a block number. This is a failure example, not a confirmed mint. Match the returned evidence to the original bank instruction and investigate before deciding whether a new instruction is appropriate.

API Reference

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

Related pages

• Handle failures
• Reconcile against your core banking
• Webhooks
• Maintenance and recovery