AXIOM: A Hybrid Classical–Quantum Architecture for Real-Time Financial Risk

1Introduction and design goals

A modern bank runs several hard computational problems at once, under regulatory scrutiny and hostile pressure. AXIOM exists to solve four of them well, in one system, without asking the institution to trust a black box.

1.1Problem context

Fraud and AML detection is a real-time, high-throughput classification problem over a graph that changes by the second. Portfolio optimization under real constraints (cardinality limits, sector caps, transaction costs) is combinatorial and NP-hard in its general form, so classical solvers approximate it under a time budget. Value-at-Risk (VaR) and its coherent successor CVaR are estimated by Monte Carlo simulation, whose error shrinks only as the inverse square root of the sample count. And the cryptography protecting all of the above is vulnerable to a future quantum adversary that can already harvest ciphertext today.

These four problems have different computational shapes. Treating them with a single hammer is how incumbents end up either slow or shallow. AXIOM instead pairs each with the right tool and stitches the results into one governed pipeline.

1.2Design principles

1. Auditability is not optional. Every decision emits a score, the reason codes behind it, the model version that produced it, and an immutable log entry. Regulators and internal model-risk teams can reconstruct any decision.
2. Latency is a first-class constraint. Real-time scoring has a hard end-to-end budget (target p99 under 8 ms). Anything that cannot meet the budget runs off the hot path.
3. Quantum where it pays, classical where it wins. A router chooses the technique per problem instance. Quantum is never used for its own sake.
4. Hardware-agnostic. Quantum backends are abstracted behind a common interface, so the same circuits run on simulators today and on improving QPUs tomorrow.
5. Secure by construction. Post-quantum key exchange and signatures are part of the data plane, not an afterthought.
6. Deploy where the data lives. On-premises or in the institution's own virtual private cloud; data does not leave the trust boundary.

1.3Non-goals

AXIOM is not a general-purpose quantum computer, nor a claim that quantum hardware today outperforms classical hardware on every task. It is not a fully autonomous decision system: high-impact actions (blocking a wire, freezing an account) surface to human review with an explanation. And it is not a data warehouse; it consumes features from the institution's existing stores rather than replacing them.

2System overview

Every decision AXIOM emits flows through the same four stages. Classical and quantum compute live in the same execution graph, and the whole path is logged.

2.1Control plane and data plane

AXIOM separates a control plane (model deployment, configuration, key management, policy) from a data plane (the hot path that scores live traffic). The control plane is where humans and pipelines act: promoting a model, rotating a key, changing a routing policy. The data plane is machine-only and latency-bound. This split lets us reason about latency and blast radius independently, and it means a control-plane outage degrades gracefully rather than stopping scoring.

2.2Deployment topology

AXIOM deploys inside the institution's trust boundary, either on-premises or in a customer-owned VPC. Quantum execution is brokered: the solver core submits jobs to a quantum backend (simulator, or a cloud QPU reached over a dedicated, post-quantum-encrypted channel) and never ships raw customer data off-site, only the abstracted problem instance (a cost matrix or a loaded distribution).

3Data and feature plane

Scoring is only as fast and correct as the features behind it. The data plane turns a raw event into an enriched, point-in-time-correct feature vector in a bounded time budget.

3.1Event ingestion

Transactions and their context arrive as an event stream (Kafka or an equivalent log). Each event carries a canonical envelope: the actor, the counterparty, the instrument, the amount and currency, the channel, and a monotonic timestamp. Events are validated against a registered schema; malformed events are quarantined rather than dropped silently, so nothing disappears without a trace.

3.2Feature store and point-in-time correctness

Features come in two shapes. Online features are low-latency lookups served from an in-memory store on the hot path. Offline features are computed in batch for training. The two are produced by the same transformation code to avoid training–serving skew, and every feature read at scoring time is stamped with the value that was true as of the event timestamp, never a future value. This point-in-time correctness is what keeps the model honest and the audit defensible.

3.3Graph construction

Fraud and laundering live in relationships. AXIOM maintains a streaming heterogeneous graph whose nodes are accounts, devices, merchants, and instruments, and whose edges are transactions, shared devices, and shared beneficiaries. The graph is updated incrementally as events arrive, and the neighborhood of the entities in a live transaction is materialized on demand for the scoring layer.

4Sentinel — fraud and AML

Sentinel scores every transaction against both the graph it sits in and the account's own history, then explains itself. It is deliberately classical: at this throughput and latency, well-built neural models win.

4.1Graph neural network core

The graph model is an inductive GNN in the GraphSAGE family with temporal attention. For a target node v, the model aggregates messages from its sampled neighborhood to produce an embedding that captures the company an account keeps, not just its own attributes. Formally, at layer k:

where α_vu are attention weights that decay with edge age, so a device shared last night matters more than one shared last year. Neighborhood sampling is capped so inference stays inside the latency budget of Table 1.

4.2Per-account sequence models

In parallel, a sequence model consumes the account's recent transaction history as an ordered series and predicts the likelihood of the next event under the account's learned baseline. A £40 coffee is unremarkable for one account and a strong signal for another; the sequence model encodes that individuality. The surprise of the observed event under this model becomes a feature.

4.3Ensemble and calibration

The graph embedding, the sequence surprise, and a set of hand-engineered velocity and rule features are combined by a gradient-boosted ensemble that outputs a raw risk score. Because a raw score is not a probability, AXIOM applies isotonic calibration so that a score of 0.9 means what it says: roughly a nine-in-ten chance of fraud on held-out data. Calibration is what makes downstream thresholds and expected-loss math trustworthy.

4.4Explainability by construction

Every score ships with its explanation, not as an afterthought bolted on for compliance but as part of the output contract. AXIOM attaches the top contributing features (via SHAP-style attributions computed against a background distribution), a human-readable reason code, and a counterfactual: the smallest change that would have flipped the decision. This is what lets a fraud analyst act quickly and a regulator audit fairly.

5Optima — portfolio optimization

Constrained portfolio selection is combinatorial. Optima formulates it, maps it to a form a quantum solver can attack, and returns allocations on the efficient frontier that time-boxed classical heuristics miss.

5.1Problem formulation

We seek weights w that maximize risk-adjusted return subject to real-world constraints. In mean–variance form with a risk-aversion parameter q:

where μ is the expected-return vector, Σ the covariance matrix, the cardinality constraint ‖w‖₀ ≤ K caps the number of held assets, and 𝒞 collects sector caps and box constraints. The cardinality constraint is what turns an easy convex program into an NP-hard combinatorial one.

5.2Mapping to QUBO / Ising

To reach a quantum solver, the discrete selection problem is cast as a Quadratic Unconstrained Binary Optimization (QUBO) over binary variables x_i ∈ {0,1} indicating asset selection (with weights discretized where needed). Constraints enter as quadratic penalty terms:

The QUBO maps directly onto an Ising Hamiltonian H_C whose ground state is the optimal selection. Penalty coefficients such as λ are tuned so that constraint violations are never favorable.

5.3QAOA with a CVaR objective and warm start

Optima uses the Quantum Approximate Optimization Algorithm (QAOA). A depth-p circuit interleaves the problem unitary e^−iγH_C with a mixing unitary e^−iβH_M, and classical optimization tunes the angles (γ, β) to minimize the measured cost:

Two engineering choices matter. First, rather than optimizing the expectation ⟨H_C⟩, Optima minimizes the CVaR of the measured energy distribution, which concentrates on the best samples and is known to converge faster for this class of problem. Second, a classical convex relaxation provides a warm start for the angles, so the quantum optimizer begins near a good basin rather than at random.

5.4Backend abstraction

The same circuit description runs across backends through a common interface, so a customer is never locked to one vendor and benefits automatically as hardware improves.

6Horizon — risk and VaR

Horizon estimates Value-at-Risk and Conditional VaR. Its advantage is not a different answer but the same answer at a target confidence with fewer samples, via quantum amplitude estimation.

6.1The Monte Carlo baseline and its ceiling

Classical Monte Carlo estimates a portfolio's loss distribution by drawing N scenarios and reading percentiles. Its statistical error shrinks as O(1/√N): to halve the error you must quadruple the work. For a large book revalued under many risk factors, that scaling is the cost driver.

6.2Quantum amplitude estimation

Quantum Amplitude Estimation (QAE) estimates the probability encoded in a prepared quantum state with error scaling as O(1/N) in the number of queries, a quadratic improvement over classical sampling:

Horizon loads the portfolio's loss distribution into a quantum register, encodes the tail-probability question as an amplitude, and uses (maximum-likelihood or iterative) amplitude estimation to read it out. VaR is then recovered by a bisection search over the threshold, and CVaR by integrating the tail.

6.3What Horizon returns

• VaR_α — the loss threshold breached with probability 1−α over the horizon.
• CVaR_α — the expected loss given a breach, a coherent risk measure preferred for capital and limits.
• Confidence intervals — every estimate ships with its interval and the sample or query budget spent, so risk teams see how converged a number is.

7Hybrid orchestration

The orchestration layer is where the "quantum where it pays" principle becomes code. It decides technique, schedules work, mitigates error, and guarantees a result within budget.

7.1The router

For each incoming job, a router chooses among a classical solver, a quantum/hybrid solver, or both (racing them and taking the first acceptable result). The decision is driven by problem size, structure, the current backend queue depth, and a learned cost model. Crucially, the router is allowed to say "classical," and often does.

Router policy (simplified)def route(job):
    if job.kind == "score":              # real-time fraud/AML
        return Classical(model=pinned)  # never on the QPU path
    if job.kind == "optimize":
        n = job.num_selectable_assets
        if n <= CLASSICAL_EXACT_LIMIT:
            return Classical(solver="branch_and_bound")
        if backend.available() and job.sla > QPU_MIN_BUDGET:
            return Hybrid(qaoa_depth=6, warm_start=True)
        return Classical(solver="heuristic")   # graceful fallback
    if job.kind == "risk":
        return race(ClassicalMC(), QuantumAE())  # first acceptable wins

7.2Scheduling and QPU brokerage

Quantum backends are a shared, queued resource with variable availability. The orchestrator batches compatible circuits, manages the queue, and applies a deadline: if a job cannot get quantum time within its budget, it falls back to the best classical result rather than blocking. Every job records which path it took, so the audit trail shows exactly how each answer was produced.

7.3Error mitigation

On real hardware, AXIOM applies standard error-mitigation techniques, readout-error calibration, zero-noise extrapolation, and measurement of a known reference problem to detect drift, so results are trustworthy without waiting for fault-tolerant machines. Mitigation choices are logged with the result.

8Aegis — post-quantum security

The cryptography protecting today's transactions is harvestable now and breakable later. Aegis is the plane that inventories that exposure and migrates it, without downtime.

8.1Threat model: harvest now, decrypt later

A capable adversary can record encrypted traffic today and store it until a cryptographically relevant quantum computer can break the public-key cryptography that protected it. For data with a long secrecy lifetime, financial records, keys, personal data, the clock has effectively already started. Aegis treats this "harvest now, decrypt later" (HNDL) risk as present, not future.

8.2Cryptographic bill of materials

You cannot migrate what you cannot see. Aegis performs automated discovery across services to build a Cryptographic Bill of Materials (CBOM): every use of RSA, ECC, and vulnerable key exchange, with its data-sensitivity and rotation posture. The CBOM prioritizes migration by exposure.

8.3Hybrid migration to NIST standards

Aegis migrates to the NIST post-quantum standards finalized in 2024, ML-KEM (FIPS 203, key encapsulation) and ML-DSA (FIPS 204, signatures), using hybrid constructions during transition. A hybrid handshake runs a classical and a post-quantum key exchange side by side and combines both secrets, so the channel is safe if either algorithm holds. Nothing breaks if a new algorithm is later found wanting.

8.4QKD-ready and key management

For the highest-value point-to-point links, the architecture can drop in Quantum Key Distribution where the physics and the budget justify it, but treats it as an option, not a default. Keys live in the institution's HSMs; Aegis integrates with existing key-management rather than replacing it.

9Serving and API

The serving layer is the contract between AXIOM and the institution's systems. It is designed for low latency, stable versioning, and answers that carry their own justification.

9.1The scoring contract

Real-time scoring is exposed over gRPC (with a REST gateway). A request carries the transaction envelope and a context reference; the response carries a calibrated score, a decision, reason codes, the model version, and a trace id that ties back to the audit log.

Response (illustrative){
  "decision": "review",
  "score": 0.912,               // calibrated probability
  "threshold": 0.85,
  "reason_codes": ["velocity_24h", "new_beneficiary", "graph_ring_risk"],
  "counterfactual": "amount < 220 would approve",
  "model_version": "sentinel-2026.01.3",
  "latency_ms": 7.4,
  "trace_id": "ax_9f31c…"          // → immutable audit entry
}

9.2Versioning and idempotency

Models are addressed by immutable version. A caller can pin a version for reproducibility or float to the current champion. Scoring is idempotent on a client-supplied key so retries never double-count, which matters when the same decision feeds ledgers and case-management systems.

10MLOps and governance

In a bank, a model is a regulated artifact. AXIOM treats the whole lifecycle, training, promotion, monitoring, and audit, as governed by default.

10.1Training and lineage

Training pipelines are reproducible: data snapshots, feature definitions, and code are versioned together so any model can be rebuilt bit-for-bit. Feature lineage is tracked from raw event to model input, which is what lets a reviewer answer "where did this number come from" with certainty.

10.2Registry, model cards, and drift

Every model is registered with a model card, its intended use, training data summary, performance across segments, known limitations, and fairness metrics. In production, AXIOM monitors input drift, score drift, and performance decay, and alerts before a stale model becomes a liability.

10.3Immutable audit

Every decision writes an append-only, tamper-evident audit entry: inputs (or their hashes, where data minimization requires), model version, score, reason codes, and the compute path taken (classical or quantum, which backend, which mitigations). The log is the backbone of both regulatory response and internal investigation.

10.4Regulatory alignment

• Model risk — designed to support SR 11-7-style validation: documented assumptions, independent testing, ongoing monitoring.
• Explainability & fairness — reason codes and segment metrics support adverse-action and anti-discrimination requirements.
• Data protection — data minimization, residency controls, and right-to-explanation support under GDPR-style regimes.
• AML — case files, typology coverage, and auditable thresholds aligned to FATF-style expectations.

11Observability and reliability

A system that makes money-moving decisions must be observable to the millisecond and resilient to the loss of any one component, including the quantum one.

11.1Telemetry

Every request is traced end to end with per-stage timing against the budget in Table 1. Metrics cover latency percentiles, throughput, flag rates, calibration error, and drift. Quantum jobs additionally record queue wait, shots, mitigation applied, and a fidelity estimate from the reference problem.

11.2Service levels and failure

The data plane carries the SLO (for example, p99 < 8 ms and 99.95% availability for scoring). The quantum path is explicitly best-effort with fallback: its unavailability degrades optimization quality or risk-estimate tightness, never the ability to make a decision. Disaster recovery replicates the control plane and model registry across zones; the data plane is stateless and horizontally recoverable.

12Benchmarks and evaluation

We benchmark against the best classical baseline available, not a strawman, and we report where quantum does not win. Numbers below are illustrative of the target and the methodology, not a hardware claim.

12.1Methodology

• Classical baselines are tuned production-grade solvers and models, given the same time budget.
• Optimization quality is measured by distance to the best-known frontier and by objective value at a fixed wall-clock budget.
• Risk estimates are compared at a fixed target confidence interval width, counting the samples or queries to reach it.
• Fraud models are evaluated on held-out, time-split data at fixed false-positive rates, never on random splits that leak the future.

The honest verdict row matters as much as the numbers. AXIOM's value is not "quantum everywhere"; it is a system that knows when quantum helps and routes accordingly.

13Limitations and current maturity

This section is deliberately blunt. Overselling quantum is how the field loses credibility with exactly the technical buyers this system is built for.

• NISQ reality. Current quantum hardware is noisy and limited in qubit count and depth. For most production sizes today, AXIOM's quantum paths run on simulators or small pilots; the classical paths carry production load.
• Crossover not yet universal. The asymptotic advantages of QAOA and QAE are real, but the problem size at which they beat tuned classical methods on real hardware is, for many workloads, still ahead of us. AXIOM is architected to capture that advantage the moment hardware crosses over, without a rewrite.
• Distribution loading. QAE's speedup assumes efficient state preparation; for complex loss distributions this is an active research area and can erode the advantage.
• Simulated figures. Every number in this document is illustrative of the target architecture. Production performance depends on data, deployment, and the chosen backend, and is established per engagement.

14Roadmap

—References and further reading

1. Farhi, Goldstone, Gutmann. A Quantum Approximate Optimization Algorithm. arXiv:1411.4028.
2. Barkoutsos et al. Improving Variational Quantum Optimization using CVaR. Quantum 4, 256 (2020).
3. Brassard, Høyer, Mosca, Tapp. Quantum Amplitude Amplification and Estimation. arXiv:quant-ph/0005055.
4. Woerner & Egger. Quantum Risk Analysis. npj Quantum Information 5, 15 (2019).
5. Egger et al. Credit Risk Analysis using Quantum Computers. IEEE Trans. Computers (2021).
6. Hamilton, Ying, Leskovec. Inductive Representation Learning on Large Graphs (GraphSAGE). NeurIPS 2017.
7. Lundberg & Lee. A Unified Approach to Interpreting Model Predictions (SHAP). NeurIPS 2017.
8. NIST. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). 2024.
9. Board of Governors of the Federal Reserve System. SR 11-7: Guidance on Model Risk Management.
10. Markowitz. Portfolio Selection. Journal of Finance 7(1), 1952.

This document describes a target architecture and design intent. All performance figures are illustrative and simulated for demonstration; production characteristics are established per deployment. © Ace Hacker Research & Development Lab.