Reconcile against your core banking

Reconcile the bank's cash and token records

Your team checks that confirmed token movements and settled balances match the bank's deposit and payment records. Keep pending instructions separate from completed movements, and give unmatched or uncertain items an investigation owner.

For issuance and redemption, match the token outcome to the corresponding bank cash posting. For locked funds, distinguish the reserved amount from money available to spend. The technology team supplies the references and reads below so finance and operations can establish what happened without repeating a payment.

Who this is for

Operations, finance and integration teams who reconcile token operations and balances against the core banking system. This page covers what to match, how to work the queue of operations that stopped, and how to establish the true state after an interruption.

Who reconciles

Your core banking system remains the book of record, and reconciliation is your bank's process. The platform does not post to or read from your core banking system. It gives you the records to reconcile against: the operation log, balances read from the token contract, and the queue of operations that stopped.

What to match

Only CONFIRMED operations have moved value. Treat every non-terminal operation as pending: do not post it, and carry it into the next run.

A reconciliation run

1. List operations. Page through GET /api/transactions, newest first. Filter by state, accountRef or txType as needed. The log has no date-range filter, so stop paging once createdAt is older than your window.
2. Match confirmed operations to your postings by transactionId.
3. Read balances for each account with GET /api/accounts/{accountRef}/balances. The figures are read from the token contract at asOf and include confirmed operations only.
4. Work the breaks queue with GET /api/transactions/breaks. See the next section.
5. Record the outcome of each exception in your own system.

Choose reconciliation cut-offs and cadence with your bank's operations team. Record the read time and unresolved instructions so a moving current balance is not mistaken for a fixed end-of-day snapshot.
Build bulk reconciliation by reading each relevant account and retaining its asOf value. The public API provides neither bulk balances nor a historical as-at read.

Working the breaks queue

GET /api/transactions/breaks lists every operation that failed or stopped moving, newest first. A row leaves the queue when its case is resolved.

breakStatus is OPEN until someone picks the case up, then INVESTIGATING. Use the operator process to assign and resolve a break; the public API reads the queue but has no status-update or resolution operation.

After an interruption

An interruption can leave the API, ledger, delivery and bank records at different stages. Do not infer rollback from a timeout or server error. To establish the true state once connectivity returns:

1. Identify the operations submitted during the interruption window. Use your own submission log, and GET /api/transactions/breaks with from and to.
2. For a submission that never returned a response, recover with the original key and unchanged body within a bounded retry budget. A recorded key returns the existing operation. Escalate unresolved acceptance or downstream evidence rather than assuming nothing happened.
3. For each operation, read GET /api/transactions/{transactionId} and act on its state.
4. If an operation confirmed but you missed the webhook, replay the event with the redelivery endpoint. See Webhooks.
5. Record the outcome of each operation.

Do not create a compensating or replacement operation until the original outcome is established. Lost event-driven announcements can require operator recovery; there is no general automatic re-drive guarantee. Reconcile cash and token evidence separately.

In a deployment your bank hosts, your bank runs this procedure, with Quant Network supporting. For Quant-hosted infrastructure, agree the recovery operator and your bank's reconciliation responsibilities in the operating model.

Reconcile two independent records

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Bank["Bank postings and business references"] --> Match["Your reconciliation process"]
    Operations["Transaction log and final states"] --> Match
    Balances["Current token balances / asOf"] --> Match
    Match --> Agree{"Records agree?"}
    Agree -->|Yes| Evidence["Retain matched evidence"]
    Agree -->|No| Investigate["Inspect operation, breaks and audit"]
    Investigate --> Resolve["Operator investigation / agreed correction"]

Compare cash and token evidence in your systems. The current balance API has no historical snapshot endpoint; retain the snapshots and confirmed operations you need. A break has no client-side resolve endpoint.

List operations · Balances · Outstanding breaks · Audit

Assign the reconciliation handover

The bank's reconciliation owner maintains the relationship between cash postings, confirmed token movements and current account balances. Quant Flow exposes operation, balance and break evidence; the operator supplies diagnosis or ledger/custody evidence when the external reads leave uncertainty.

Record each exception with its account, asset, bank reference, original key, operation ID, observed state and ledger identifiers. Keep the bank's investigation status in its own system; the external break API cannot update it. After maintenance, reconcile the pending-work inventory before reopening affected submissions. Static reserve/dashboard figures are not substitutes for this evidence. Follow Daily operations and monitoring and Maintenance and recovery.

Worked example

List confirmed operations originating from one account:

GET /api/transactions?state=CONFIRMED&accountRef=ACC-0001&page=0&size=20 HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0

Illustrative example built from the schema.

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

{
  "content": [
    {
      "transactionId": "9c4d2f18-73ba-4e6c-8f05-2d17ab903e64",
      "txType": "LOCK",
      "assetId": "GBP",
      "accountRef": "ACC-0001",
      "customerRef": "CUST-0001",
      "counterpartyRef": "ACC-0002",
      "amount": "100.00",
      "params": {
        "expiry": "2027-01-01T00:00:00Z",
        "lockRef": "INV-88421",
        "lockId": "b28f1a4c-9d3e-4f27-8a56-1e0c7b9d42a1"
      },
      "state": "CONFIRMED",
      "txHash": "0x9f2c1d5e4b8a37c06d1e5f9a2b4c7d8e0f1a2b3c4d5e6f708192a3b4c5d6e7f8",
      "blockNumber": 18446744,
      "createdAt": "2026-08-06T09:29:10.285Z",
      "updatedAt": "2026-08-06T09:31:47.902Z"
    }
  ],
  "page": 0,
  "size": 20,
  "totalElements": 1,
  "totalPages": 1
}

Match transactionId and params.lockRef to your payment record, and txHash to the ledger receipt.

Then read the account's balance:

GET /api/accounts/ACC-0001/balances 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",
  "total": "1250.00",
  "available": "1210.00",
  "locked": "40.00",
  "asOf": "2026-08-13T11:58:04.114Z"
}

View in API Reference

• List token operations · GET
• Get an account's balances · GET

Errors and edge cases

• The accountRef filter matches operations originating from the account. A transfer naming it as the counterparty is not matched. To reconcile receipts, list the sending accounts' operations, or rely on the receiving account's balance.
• Treasury timestamps use ISO 8601 UTC with three fractional digits. Breaks occurredAt can be sent back as a from filter. Webhook delivery timestamps retain their separately documented format.
• A balance read that fails returns 500. Never treat it as a zero balance.
• Reserve figures are static today. GET /api/reserves/attestation returns static figures pending a core banking integration. Do not reconcile against them. See Limitations. Use bank-held reserve records for reconciliation while these endpoints return static data.

API Reference

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

Related pages

• Balances
• Operations and their lifecycle
• Handle failures
• Issue and redeem
• Audit and evidence

Implementation resources

Reserves code recipes.

Use Implement a backend client for request handling, durable idempotency and outcome tracking. The developer integration coverage map links every public operation to its API Reference and contract-derived code recipe. Replace example identifiers with values from your assigned environment.