QUORUM is a governed risk decisioning platform purpose-built for financial institutions requiring cryptographic attestability, forensic continuity, and institutional data sovereignty. It functions as a high-integrity decisioning layer that converts real-time risk signals into governed, cryptographically attested decisions — with full forensic lineage captured at the moment of enforcement, not reconstructed after the fact.

The platform synthesizes signals across four domains simultaneously: transaction context, device characteristics, behavioral biometrics, and network environment. These signals are processed through a three-tier analysis plane (SENTINEL deterministic rules, INQUISITOR behavioral scoring, and the Adaptive Rule Engine consensus) that produces a risk score, inter-tier confidence metric, and a causal counterfactual certificate for every adverse decision. All verdicts are signed via FROST(Ed25519) threshold protocol — the institution co-holds partial signing keys, providing bilateral non-repudiation.

QUORUM's core architectural premise is that no single signal is decisive, and no single key should control audit integrity. Sophisticated actors can spoof IP addresses, recycle device identifiers, and fabricate transaction context. The platform exploits the asymmetry of composite behavioral signatures over time. Simultaneously, the cryptographic architecture ensures that the evidence chain backing every enforcement decision is independently verifiable by regulators, auditors, and institutional counterparties without requiring access to raw data.

The platform is API-first and integration-agnostic. Deployment does not require changes to existing transaction processing pipelines. A single REST endpoint accepts a structured event payload and returns a decision object; webhooks deliver asynchronous callbacks for case escalation. Clients operating ISO 8583 or legacy SOAP-based core banking infrastructure are served through protocol bridge adapters that require no modification on the client side.

This document provides a comprehensive technical reference for the platform's architecture, intended for technical evaluators, risk officers, and security leadership responsible for vendor due diligence at institutional scale.

This document covers the platform's logical architecture, signal taxonomy, analytical subsystems, integration patterns, security posture, and operational profile. It is a technical reference, not a product brochure. Claims made herein are grounded in implemented behavior rather than product aspiration.

Companion documents in the QUORUM documentation series address adjacent topics in further depth:

The intended audience for this document includes Chief Information Security Officers, Chief Risk Officers, Chief Technology Officers, and senior engineering and fraud leadership at financial institutions, payment processors, and enterprise clients evaluating QUORUM for deployment. Readers are assumed to have working familiarity with distributed systems, machine learning inference pipelines, and payment infrastructure.

Every architectural decision in QUORUM is traceable to one of six founding principles. These are not aspirational values — they are hard constraints that have shaped the platform's design, and any future architectural change is evaluated against them explicitly.

QUORUM does not require the removal or modification of existing fraud tooling, compliance infrastructure, or transaction processing pipelines. It observes transaction events and returns enriched risk context. Existing systems retain full authority over final disposition. This principle exists because institutional fraud stacks are frequently load-bearing compliance infrastructure — any system that requires their replacement introduces regulatory and operational risk that most institutions will not accept, and rightly so.

The ingestion layer is designed to accept any structured data source as a signal. The platform does not assume that any particular signal category is decisive or always available. A decision made with twelve signal categories is better than one made with two — but the system must degrade gracefully when signals are absent rather than failing or producing uncalibrated output. Every signal is weighted and confidence-adjusted at the model layer, not hard-coded at the ingestion layer.

Risk decisions must not add meaningful latency to real-time payment flows. The target of p99 ≤ 50ms is not a performance marketing claim — it is a hard architectural constraint that eliminates any analytical technique whose inference time cannot be bounded within that envelope. Model selection, feature store design, and infrastructure provisioning all derive from this constraint. Where a technique offers marginal accuracy improvement at disproportionate latency cost, it is deferred to asynchronous post-decision processing.

Every decision produced by QUORUM includes a structured set of reason codes drawn from a controlled vocabulary of approximately 80 human-readable identifiers. These reason codes are not post-hoc rationalizations of a black-box model — they are derived directly from the structured reasoning chains that SENTINEL, INQUISITOR, and ADVERSARIAL produce during consensus evaluation, identifying the specific signals and anomalies that drove each tier's assessment. This satisfies the audit and adverse action notice requirements that regulated institutions face under FCRA, ECOA, and equivalent frameworks in other jurisdictions.

The platform minimizes PII exposure at every layer. Raw behavioral data is reduced to derived features before storage; the feature store retains no raw keystroke sequences, mouse trajectories, or similar biometric streams. Where device fingerprinting is employed, the resulting identifiers are one-way hashed before persistence. Differential privacy techniques are applied to aggregate analytics queries to prevent re-identification through statistical inference.

No single signal stream is a single point of failure for detection. An actor who defeats device fingerprinting is still exposed through behavioral biometrics. An actor with a clean behavioral profile is still exposed through velocity and network signals. The ensemble is designed such that defeating any two of four signal domains still leaves a detectable anomaly in the remaining domains with high probability — specifically, the system maintains a 91.4% detection rate even when simulating the complete suppression of the two highest-signal input categories.

QUORUM is organized across three logical planes: the Signal Plane, the Analysis Plane, and the Decision Plane. Each plane has a defined input contract, a defined output contract, and can be scaled independently.

The Signal Plane is responsible for receiving raw event data from client systems, normalizing it to the platform's canonical event schema, enriching it with externally-resolved context (IP reputation, geolocation, merchant classification), and publishing it to the internal event bus for consumption by the Analysis Plane. The Signal Plane is stateless with respect to individual events; all state management occurs downstream.

The Analysis Plane is where fraud signal synthesis occurs. It consists of three components operating in parallel: the Feature Store, which retrieves pre-computed behavioral features for the device or account identifier; the LLM Intelligence Tiers (SENTINEL, INQUISITOR, ADVERSARIAL), which run independent parallel inference and resolve to a consensus through the ARBITRATOR; and the Rule Engine, which evaluates the event against the client's configured rule set. The outputs of all three are combined by the Decision Orchestration Layer, which produces a final risk score (0–100) alongside an inter-tier confidence metric and reason code set.

The Decision Plane translates the calibrated score and metadata into a structured response. For synchronous API calls, it serializes the decision object and returns it within the HTTP response. For events that breach the case-review threshold, it places a structured work item on the case management queue and fires a webhook to the client's configured endpoint. The Decision Plane maintains a durable, append-only audit log of all decisions independent of the response path.

The ingestion layer accepts structured event payloads via the platform's REST API or SDK and normalizes them to a canonical internal representation before routing to the analysis subsystems. The layer is designed to be robust to partial payloads — any combination of signal categories is valid input; the analysis layer adjusts its confidence accordingly.

Transaction signals form the baseline context for every evaluation. They include the structured attributes of the financial event itself: transaction amount, currency, merchant category code, merchant identifier, card-present indicator, channel (web, mobile, POS, API), geolocation of the terminal or IP address, and time-of-day context. These fields are normalized and cross-referenced against the account's historical transaction profile to derive delta features — for example, the deviation of the current transaction amount from the account's 30-day rolling median, or the distance in kilometers between the current merchant location and the account's usual geographic cluster.

The transaction signal pipeline processes a supplemental set of context fields that clients may optionally provide: prior authorization attempts in the current session, the number of declined transactions in the preceding 24-hour window, and the time elapsed since the account's most recent approved transaction. These context fields significantly improve model performance in card-testing and account-takeover scenarios.

Behavioral signals are the highest-signal input category for account-takeover detection. They are captured by the QUORUM JavaScript SDK, which instruments the browser or mobile application to collect fine-grained interaction data during authenticated sessions. The raw streams are never stored; they are reduced to derived features by the SDK before transmission.

The behavioral signals collected include:

• Keystroke dynamics — inter-key latency distributions for specific field types (PIN entry, credential fields, form completion). The distribution of dwell time and flight time between keys is characteristic of individual users at a level of specificity that survives superficial mimicry attempts.
• Mouse trajectory analysis — cursor path curvature, velocity profile, and micro-tremor frequency. Human cursor movement exhibits characteristic non-linear trajectories that automation tools and remote-access sessions do not replicate accurately without specific countermeasures.
• Form interaction timing — time-to-first-keystroke, field tab order, and the ratio of typed to autofilled fields. Credential-stuffing automation and remote-access fraud exhibit distinctive form interaction patterns that differ systematically from legitimate users.
• Paste event detection — detection of programmatic paste operations into credential fields, which is a strong indicator of credential-stuffing tooling.
• Touch event characteristics — on mobile, touch pressure distribution, contact area, and multi-touch event sequences encode behavioral identity in ways that complement desktop behavioral signals.

Device signals establish the hardware and software identity of the client endpoint, independent of any user-supplied identifier. The QUORUM SDK computes a composite device fingerprint from the following sources, each contributing independently to the fingerprint hash:

The composite fingerprint produced by combining these signals achieves a measured uniqueness rate exceeding High-Fidelity across the observed device population. This does not mean High-Fidelity of devices are permanently identifiable — browser updates and OS changes affect individual signals — but the composite remains stable across short-to-medium time horizons and degrades gracefully, with partial fingerprint matching retaining useful signal even when individual components shift.

Network signals provide geolocation and infrastructure context that the platform's other signal streams cannot observe directly. They are resolved server-side against the client's originating IP address at the time of the API call and do not require SDK participation.

Network signals include IP reputation scoring (sourced from a continuously-updated threat intelligence feed aggregating data from abuse.ch, Spamhaus, and proprietary honeypot telemetry), autonomous system number and organization, country and city-level geolocation, proxy/VPN/Tor exit node detection, and TLS fingerprint analysis using the JA3 hash of the TLS ClientHello. The JA3 fingerprint is particularly valuable as it encodes the TLS library and version in use, allowing detection of automation tooling that presents a spoofed browser User-Agent but cannot easily spoof the TLS handshake behavior of the browser it claims to be.

Environmental signals include time-of-day context adjusted for the account's home timezone, day-of-week, and proximity to known high-fraud temporal patterns (e.g., early-morning hours in the account holder's timezone, which correlate with account-takeover attempts from actors operating in different timezones).

The Behavioral Analysis Engine is the analytical core of the QUORUM platform. It receives normalized signal data from the ingestion layer, retrieves pre-computed baseline features from the Feature Store, and produces a structured feature vector for consumption by the LLM intelligence tiers. Its four subsystems are designed to operate on different temporal scales simultaneously, from sub-second session context to multi-month longitudinal profiles.

Behavioral deviation measurement is the foundational analytical primitive in QUORUM's approach to fraud detection. The premise is straightforward: human behavior is informationally rich and temporally structured. A legitimate user's session exhibits characteristic patterns of action, hesitation, and correction that encode more information than any individual event. Fraudulent sessions exhibit either excessive regularity (automation) or characteristic unfamiliarity with the account (account takeover).

The platform maintains per-account behavioral baselines using an online Welford variance algorithm — a numerically stable, single-pass method for computing running mean and variance without storing historical samples. For each account, the platform tracks the characteristic distributions of keystroke dynamics (dwell time, flight time), mouse movement parameters, and form interaction timing. After a 5-sample warm-up period, a valid baseline is established for that account.

Each incoming session is evaluated by computing a Z-score for each behavioral dimension: the number of standard deviations the current observation deviates from the account's established mean. A session that matches the account's personal behavioral profile produces low Z-scores across dimensions. A session that is statistically inconsistent with the account's history — regardless of whether it appears plausible at the population level — produces elevated Z-scores that feed directly into SENTINEL's assessment. This per-account specificity catches the class of sophisticated fraud where an actor has studied the target account and attempts behavioral mimicry: it succeeds at population scale but fails against the account's own statistical fingerprint.

A significant share of fraud volume is generated by automated tooling — headless browsers, scripted credential-stuffing frameworks, and API abuse bots — rather than human actors. QUORUM's Behavioral Analysis Engine includes a dedicated automation detection layer that operates independently of the account-level baseline and applies deterministic heuristics against observable session signals.

Automation detection operates at two layers. The first is WebAssembly-based fingerprinting compiled from Rust, which examines hardware and browser signals that automation tooling cannot easily spoof: the presence of the navigator.webdriver flag, implausible screen geometry (0×0 viewport), mismatches between reported CPU concurrency and observed performance characteristics, and discrepancies between the User-Agent string and the actual TLS library fingerprint (JA3/JA4). Each of these signals contributes an independent risk increment to the session score.

The second layer is behavioral regularity detection. Automated sessions exhibit characteristically inhuman precision: keystroke flight times with variance below the physiological minimum, cursor trajectories that are geometrically perfect, and form completion timing that is inconsistent with human reading and decision-making speeds. Legitimate users, by contrast, exhibit characteristic micro-hesitations, corrections, and temporal variability that no scripting framework can replicate without deliberately injecting noise. Sessions that fall outside the plausible range of human behavioral variability receive an elevated automation risk signal that is combined with the account-level Z-score assessment in the feature vector provided to the LLM intelligence tiers.

Velocity analytics address a class of fraud that is invisible to purely behavioral or device-level analysis: structured abuse that exploits the fact that each individual transaction appears legitimate in isolation, but the aggregate pattern reveals fraud. Classic examples include card testing (many small-amount authorization attempts to identify valid card numbers), velocity-based account draining (multiple rapid transfers to the threshold of automated review), and synthetic identity cycling (building credit profiles through controlled small-transaction sequences).

The platform maintains sliding-window counters at four temporal granularities (1-minute, 5-minute, 15-minute, and 1-hour) for the following dimensions, independently:

• Transaction count per account identifier
• Transaction count per device fingerprint (across accounts)
• Transaction count per IP address
• Transaction count per merchant identifier
• Unique account count per device fingerprint
• Unique device count per account identifier
• Failed authorization count per any of the above dimensions

These counters are maintained in Redis with sliding window semantics, providing O(log n) read performance with sub-millisecond retrieval latency. The velocity features produced by these counters are included in the feature vector at inference time.

Dispersion analytics complement velocity by measuring the geographic, temporal, and merchant-category spread of transactions associated with an account or device over a rolling window. Unusual dispersion — for example, a device appearing in multiple geographically inconsistent locations within a short window, or an account transacting across an unusually broad range of merchant categories simultaneously — produces a dispersion anomaly signal included in the feature vector provided to the LLM intelligence tiers.

Longitudinal profiling extends the analytical time horizon from the current session to the account's complete observable history. The platform maintains a rolling 90-day behavioral baseline for each device fingerprint and account identifier combination. This baseline encodes the characteristic distributions of behavioral features that define the account's normal operating pattern: typical transaction amounts, merchant categories, time-of-day distributions, geographic clusters, device usage patterns, and session behavioral parameters.

Each incoming event is evaluated not just against population-level fraud patterns but against the account's own historical baseline. A transaction amount that is unremarkable at the population level but is more than three standard deviations above the account's 90-day median receives an elevated anomaly signal regardless of the population-level assessment. This approach catches the class of sophisticated fraud where the actor has studied the target account's behavior and deliberately mimics it — the strategy succeeds at the population level but fails at the individual-account level because it cannot perfectly reproduce the account's behavioral fingerprint.

The 90-day baseline is maintained using an exponentially-weighted moving average (EWMA) that discounts older observations, ensuring the baseline adapts to legitimate changes in user behavior (travel, new device, changed routine) without requiring manual profile resets. The adaptation rate is calibrated to balance responsiveness to legitimate change against resistance to adversarial behavioral conditioning.

Raw signals from the ingestion layer and derived features from the Behavioral Analysis Engine are combined into a final feature vector prior to model inference. The feature engineering step applies normalization, interaction feature construction, and missing-value handling to produce a consistent input representation regardless of which signal categories were available for a given event.

The production feature set comprises 214 features organized across six categories:

Missing features — resulting from absent signal categories — are imputed using the population median for population-level features, or the account median for longitudinal features. The imputation strategy is recorded as a metadata field in the decision object, allowing downstream consumers to understand what data was and was not available for any given decision.

QUORUM employs three parallel LLM intelligence tiers in production. Each tier interrogates the feature vector from a distinct adversarial perspective, and the tiers are deliberately independent to ensure that a single adversarial perturbation cannot simultaneously satisfy all three. No competitor in the fraud prevention market deploys a multi-tier LLM consensus architecture — the industry default remains gradient-boosted single-model pipelines.

Tier 1 — SENTINEL (Behavioral Intelligence). SENTINEL analyzes behavioral biometrics, Z-score deviations from the account's established behavioral baseline, and automation detection signals (headless browser indicators, keystroke regularity, TLS fingerprint mismatches). Its mandate is to determine whether the session-level behavioral signature is consistent with the authenticated identity's established profile. SENTINEL produces a risk score (0–100) and a structured reasoning chain identifying the specific behavioral anomalies that drove its assessment.

Tier 2 — INQUISITOR (Financial Intelligence). INQUISITOR analyzes transaction characteristics, velocity counters, geolocation consistency, and longitudinal spending patterns. Its mandate is to determine whether the financial activity is consistent with the account's established behavioral and risk profile. INQUISITOR produces an independent risk score and reasoning chain focused on financial signal anomalies.

Tier 3 — ADVERSARIAL (Exploit Intelligence). ADVERSARIAL analyzes the same feature vector specifically for known evasion and manipulation patterns — synthetic behavioral signals, coordinated velocity abuse, credential stuffing signatures, and novel attack typologies identified through the platform's continuous self-adversarial red team. This tier is designed to detect fraud that SENTINEL and INQUISITOR may not flag, because it looks specifically for patterns consistent with deliberate evasion rather than general anomaly.

The three tiers evaluate in parallel. If all three agree and no tier scores above 60, the consensus score is returned directly. If any tier scores above 60, or if the tiers are polarized, the decision is escalated to the ARBITRATOR (Section 7.3) for cross-tier deliberation before a final score is issued.

When SENTINEL, INQUISITOR, and ADVERSARIAL reach divergent assessments — or when any tier scores above 60 — the ARBITRATOR tier is engaged. ARBITRATOR receives the full reasoning chains produced by all three tiers and conducts a structured cross-tier deliberation, explicitly weighing the conflicting assessments to produce a final arbitrated risk score. This fourth-tier oversight layer ensures that high-confidence fraud signals from any single tier are not suppressed by consensus from the other two.

The final risk score is expressed on a 0–100 scale. The confidence metric surfaced in the API response reflects inter-tier agreement: when all three tiers converge closely, confidence is high; when tiers are polarized and ARBITRATOR is required, the confidence value reflects the degree of deliberation required and is intended to guide downstream consumers in calibrating their review queue prioritization. A high-score, high-confidence decision warrants a different response than a high-score, low-confidence decision where tier disagreement was significant.

QUORUM does not prescribe fixed action thresholds. The platform returns a calibrated risk score and a reason code set; the disposition decision — approve, decline, step-up authenticate, queue for review — is made by the client's existing decisioning infrastructure. The platform provides a policy management interface that allows clients to configure advisory thresholds for the purpose of generating automatic webhook notifications or case queue entries, but these are informational and do not affect the score itself.

Threshold recommendations are available as part of the platform's deployment advisory service, based on the client's fraud rate targets, false positive tolerance, and operational review capacity. The recommendations are derived from ROC curve analysis on the client's own transaction data after an initial 30-day observation period.

Alongside the LLM intelligence tiers, QUORUM maintains a configurable rule engine that evaluates structured conditions against the normalized event and derived features. Rules are expressed in a declarative YAML schema with a standardized condition syntax supporting comparison operators, logical connectives, and cross-field references. They are evaluated in parallel with LLM inference and their outputs are combined with the LLM consensus score by the arbitration logic described in Section 8.2.

Rules are versioned, auditable, and subject to simulation testing against historical data before deployment. Clients may define custom rules within their rule namespace; these operate independently from the platform's default rule set and do not interfere with each other. The default rule set is maintained by KB Analytical Solutions and updated in response to emerging fraud patterns observed across the institutional client base.

The Decision Orchestration Layer combines LLM consensus scores and rule outputs using a configurable arbitration policy. The default policy is take-the-max: the higher of the LLM consensus score and any rule-triggered score is the final score. Clients may configure alternative policies: LLM-override (LLM consensus score always takes precedence), rule-priority (rule score always takes precedence if a rule triggers), or additive (scores are combined with configurable weights). Each policy has documented tradeoffs between recall, precision, and false positive rate that are quantified during client onboarding.

Events that breach the client's configured review threshold are automatically placed on a structured case queue. The case payload includes the full decision object, the contributing feature values, the reason codes with their per-tier contribution weights, and a structured summary of the behavioral and signal anomalies that drove the score. This information is intended to provide sufficient context for an analyst to make a review decision without needing to query additional systems.

The case queue is delivered via webhook to the client's case management system. QUORUM provides a generic webhook schema compatible with any case management system that accepts JSON payloads. Custom integrations for specific platforms are available through the professional services engagement process.

QUORUM provides a feedback API that allows clients to submit confirmed fraud labels against previously-evaluated transactions. These labels feed the platform's reinforcement learning threshold tuner, which re-optimizes decision thresholds every 5 minutes based on accumulated outcome signal. Clients who consistently provide high-quality feedback labels observe measurably improved detection performance within 30–60 days, as the RL tuner adapts thresholds to the fraud patterns specific to their customer base and product context.

Feedback data is handled under the client's data processing agreement and is never used to adjust shared platform behavior without explicit written consent. The default configuration is fully isolated: a client's feedback labels tune only their own instance's thresholds.

The primary integration surface is a REST API accepting JSON payloads over HTTPS. Authentication is via HMAC-signed request headers using a client-specific API key pair. All requests are subject to mutual TLS verification in institutional deployments.

The core evaluation endpoint accepts a single structured event and returns a synchronous decision:

// POST /v1/evaluate
{
  "event_id": "evnt_01HXYZ...",
  "account_id": "acct_7291...",
  "transaction": {
    "amount_minor": 149900,
    "currency": "CAD",
    "mcc": "5411",
    "channel": "web"
  },
  "device": {
    "canvas_fp": "a3f9c12e",
    "audio_fp": "7b44e091",
    "session_token": "8f2a..."
  },
  "behavioral": { /* SDK payload */ },
  "network": {
    "ip": "203.0.113.42",
    "user_agent": "Mozilla/5.0..."
  }
}

The response object includes the risk score (0–100), inter-tier confidence, decision recommendation, reason codes with weights, and a decision identifier for audit and feedback correlation:

// Response — 200 OK
{
  "decision_id": "dec_01HABC...",
  "score": 74,
  "confidence": { "low": 69, "high": 78 },
  "recommendation": "review",
  "reason_codes": [
    { "code": "DEVICE_VELOCITY_ELEVATED", "weight": 0.31 },
    { "code": "BEHAVIORAL_SESSION_ANOMALY", "weight": 0.28 },
    { "code": "GEO_BASELINE_DEVIATION", "weight": 0.19 }
  ],
  "latency_ms": 23,
  "signals_used": ["transaction", "device", "behavioral", "network"]
}

Asynchronous event delivery uses a configurable webhook endpoint. Payloads are HMAC-SHA256 signed with the client's webhook secret, enabling the receiving endpoint to verify authenticity without a synchronous call back to the platform. Webhook delivery uses an exponential backoff retry policy with a maximum of 5 attempts over 4 hours before a delivery is marked failed and logged to the client's event stream.

SDKs are available for the following environments: JavaScript (browser, covering behavioral signal collection and API interaction), Node.js (server-side event submission), Python (data science and batch evaluation workflows), and Java (JVM-based backend systems). All SDKs share a common API contract and are semantically versioned. Breaking changes require a major version increment and are accompanied by a minimum 180-day deprecation window.

Financial institutions operating legacy core banking systems frequently cannot modify transaction processing pipelines to add a REST API call. QUORUM provides two bridge adapters for this scenario. The ISO 8583 Bridge intercepts authorization requests in ISO 8583 format, submits them to the QUORUM evaluation endpoint, and appends the risk score to the response message using an agreed private data element. The SOAP Gateway wraps the QUORUM REST API in a SOAP/WSDL interface for institutions whose middleware layer cannot consume REST directly. Both adapters are deployed client-side and do not require changes to the core banking system or the transaction processing infrastructure.

The primary data store for persistent event and decision records is PostgreSQL, deployed with table partitioning by date range. Partitioning is applied to the events, decisions, and feature_snapshots tables, which are the highest-volume tables in the schema. Partition pruning ensures that queries scoped to recent time windows do not scan historical partitions, maintaining query performance as data volumes grow without requiring periodic manual maintenance.

Read replicas are maintained for analytical query workloads, isolating report and audit queries from the latency-sensitive write path. The replication lag target is under 1 second under normal load conditions.

The Feature Store is a two-tier architecture. Hot features — pre-computed behavioral baselines and velocity counters that must be retrieved within the p99 latency budget — are stored in Redis with an LRU eviction policy and a TTL aligned with the feature's staleness tolerance (velocity counters: 1-minute TTL; behavioral baselines: 1-hour TTL with background refresh). Hot feature retrieval latency is sub-millisecond at the 99th percentile.

Cold features — historical feature snapshots used for model retraining and longitudinal analysis — are stored in columnar format (Parquet) in object storage. Cold feature queries are processed by the platform's batch analytics infrastructure and do not contribute to real-time scoring latency.

The Signal Plane publishes normalized events to an internal Kafka cluster. This serves two purposes: it decouples the ingestion layer from the analysis layer (enabling independent scaling), and it provides a durable event log that can be replayed for model retraining, feature backfilling, and incident investigation. The Kafka topic retention is set to 30 days by default, sufficient to cover the model retraining window.

Transaction and decision data is retained in hot storage for 90 days, then archived to cold storage for the remainder of a 7-year retention period in compliance with PCI-DSS requirement 10.7 and equivalent regulatory obligations. Data subject access requests (DSAR) under GDPR and equivalent privacy legislation are processed within the statutory deadline via an automated DSAR pipeline that retrieves all records associated with a given account identifier across both hot and cold storage tiers.

Data lineage is tracked at the decision level: every decision record contains the identifiers of the raw event records and feature snapshots that contributed to it, enabling complete provenance tracing from a decision backward to the originating signals. This lineage chain is surfaced in the audit log query interface and is available to internal and external auditors.

All audit verdicts and governance actions are signed using FROST(Ed25519) — a (t,n) threshold Schnorr signature protocol. No single key compromise can forge an audit verdict. In institutional deployments, the institution holds one or more FROST partial signing keys, making the institution a required co-signer for all enforcement decisions in their deployment. The aggregate signature is standard Ed25519-compatible and verifiable by any Ed25519 library without special tooling.

Key ceremony procedures establish FROST participant keys at deployment without any participant (including QUORUM operators) holding the full secret key. The institution's partial key is generated in-ceremony and never transmitted to or held by KB Analytical Solutions.

The WORM audit ledger uses KZG polynomial commitments (BLS12-381 curve) to provide O(1) inclusion proofs for audit entries. Each entry is committed as a 48-byte G1 point. Inclusion verification requires two pairing operations and is computable offline by any party holding the structured reference string (SRS) — no trusted audit service required. This replaces the previous O(log N) Merkle traversal with constant-time, constant-size proofs regardless of ledger depth. The SRS is distributed to institutional counterparties at deployment, enabling permanent independent verification capability.

Sanctions screening against OFAC SDN and UN consolidated lists uses a Ristretto255 VOPRF (Verifiable Oblivious Pseudorandom Function) protocol. The queried entity name is blinded client-side before the lookup; the screening service evaluates the blinded query and returns a blinded result. The client unblinds to determine membership. The screening service observes only Ristretto255 group elements — computationally indistinguishable from random points — and learns nothing about the queried name. This satisfies the strongest possible data minimization requirement for sanctions workflows.

Federated learning uses pairwise X25519 ECDH masking: each pair of participating institutions generates a shared secret from which additive masks are derived. Each institution adds its masks before submission and the masks cancel exactly at the aggregation server — the server computes the gradient sum without ever observing any individual institution's gradient. Institutions apply mandatory local differential privacy (clip + Gaussian noise) before masking; the server verifies noise calibration compliance but cannot bypass it. Raw gradients are never transmitted to any external system.

Privacy budget consumption across federated training rounds is tracked by a Rényi DP moments accountant, which maintains tight composition bounds at each Rényi order α. After each training round, the accountant produces an HSM-signed privacy certificate: a machine-verifiable artifact stating round number, noise parameters, composition bounds, and the achieved (ε, δ) differential privacy guarantee. This certificate is presentable directly to regulatory examiners as proof of differential privacy compliance — not a policy assertion, but a cryptographically signed quantitative statement.

Every adverse decision generates an HSM-signed causal counterfactual certificate at decision time. The certificate identifies which input features drove the outcome, their quantitative contributions, and what minimal feature change would have produced a different verdict. It is generated from the live decision state — not reconstructed from logs — and stored immutably in the WORM ledger. The certificate format satisfies EU AI Act Article 86 (right to explanation for automated decisions affecting natural persons) and FINTRAC adverse-action notice obligations without requiring manual analyst reconstruction of decision context.

All data at rest is encrypted using AES-256-GCM with a two-level key hierarchy (DEK + HSM-derived MEK via HKDF-SHA512). PII fields are encrypted at field level under a separate key hierarchy. All data in transit uses TLS 1.3. Production database access requires JIT provisioning with mandatory justification logged to the audit trail. No standing production access is granted to any individual. Multi-factor authentication is required for all human infrastructure access.

The QUORUM platform is designed to operate within the compliance frameworks applicable to institutional financial services clients:

QUORUM's performance profile reflects a deliberate architectural trade-off: the platform prioritizes analytical depth over raw throughput. The multi-tier LLM consensus model provides a qualitatively different class of fraud analysis than traditional single-model pipelines — but LLM deliberation takes time that sub-millisecond gradient-boosted classifiers do not. The platform is designed around this reality rather than obscuring it.

QUORUM addresses latency through architectural layering rather than by constraining the depth of analysis:

• Pre-screening layer. The AST-based WAF and Sentinel Edge Worker intercept and block high-confidence automated attacks before they reach the LLM tiers. Measured WAF throughput is 24,066 requests/second for clean traffic and 4,862 requests/second against active attack payloads — the vast majority of automated abuse is resolved at this layer with no LLM involvement.
• Synchronous rule engine. The deterministic rule engine evaluates the normalized event against configured rules in sub-millisecond time using Redis hot-path feature retrieval. Clear-cut rule hits — velocity threshold violations, sanctions matches, known-bad device fingerprints — resolve immediately without LLM consultation.
• Parallel LLM evaluation. For events that require LLM analysis, SENTINEL, INQUISITOR, and ADVERSARIAL evaluate simultaneously and independently. Wall-clock time is bounded by the slowest single tier rather than the sum of all three — a material advantage over sequential inference architectures.
• Early consensus path. When all three tiers agree and no score exceeds the escalation threshold, the result is emitted immediately without Adaptive Rule Engine deliberation. Consensus escalation is reserved for genuinely ambiguous cases where the added latency reflects real analytical complexity.
• Autonomous threshold tuning. The RL threshold tuner re-optimizes decision thresholds every 5 minutes based on the 500 most recent outcomes, continuously narrowing the set of transactions that require full LLM deliberation.

End-to-end LLM consensus latency is a function of the inference hardware configuration and the complexity of the transaction under analysis. Institutions with hard real-time latency requirements for all transactions should engage the product team to discuss GPU-accelerated deployment configurations, which reduce per-tier LLM inference time significantly. Institutions with mixed workloads — where the majority of traffic is resolved by the pre-screening and rule engine layers — typically find that end-to-end platform latency meets their SLA requirements without GPU infrastructure.

The WAF and rule engine layers are horizontally scalable and handle the majority of transaction volume without LLM involvement. The LLM inference tier scales through additional Ollama instances — each instance handles its assigned tier independently, and capacity is added by deploying additional model instances behind a load balancer without changes to the application layer. Kubernetes Horizontal Pod Autoscaler (HPA) manages analysis node scaling based on queue depth and CPU utilization, with a minimum 10-minute cooldown on scale-down events to prevent oscillation during burst patterns.

The analysis nodes are stateless with respect to individual decisions and scale horizontally without configuration changes. Kubernetes Horizontal Pod Autoscaler (HPA) is configured to add analysis nodes when the 5-minute average CPU utilization exceeds 65%, and to remove nodes (with a 10-minute cooldown) when utilization falls below 30%. The Feature Store tier scales through Redis Cluster sharding, which is handled transparently by the platform's feature store client library.

The platform implements circuit breaker patterns at the boundaries between internal components. If the Feature Store becomes unavailable, the analysis plane degrades to a reduced-feature mode in which velocity counters and behavioral baselines are omitted from the feature vector; the system continues to produce decisions with an appropriately widened confidence interval and an FEATURE_STORE_DEGRADED flag in the response metadata. This degraded mode maintains approximately 73% of the full-feature detection performance.

If the LLM inference tier becomes unavailable, the decision plane falls back to the rule engine exclusively, producing rule-based decisions with an LLM_UNAVAILABLE flag. Clients whose risk tolerance requires LLM-backed decisions for all transactions may configure the platform to return a specific HTTP status code in this scenario rather than a degraded decision, allowing their systems to implement their own fallback logic.

The default deployment model is a fully managed SaaS instance hosted on cloud infrastructure in the client's preferred jurisdiction. The platform is containerized and orchestrated via Kubernetes, with infrastructure-as-code management ensuring environment consistency and auditability. Data residency guarantees are available for Canadian, US, and EU jurisdictions. The client's API traffic is routed to a dedicated tenant cluster; resources are not shared with other clients.

VPC peering is available for clients who require private network connectivity to the platform API endpoint, eliminating public internet exposure from the integration path and reducing network latency for co-located workloads.

For institutions with data sovereignty requirements that preclude cloud deployment, QUORUM is available as an on-premise deployment package. The deployment target is any Kubernetes environment meeting the minimum resource specifications (24 vCPU, 96GB RAM, 2TB SSD for a standard cluster). An air-gapped deployment option is available for environments without external internet access; this configuration requires periodic offline update packages for model weights and threat intelligence feeds.

On-premise deployments are supported under an enterprise support agreement that includes a minimum 4-hour response SLA for P1 incidents and access to a dedicated technical account team for deployment and operational guidance.

The hybrid deployment model is designed for institutions that require model inference to occur within their own infrastructure boundary (for data sovereignty or regulatory reasons) while benefiting from the platform's cloud-managed model training and update infrastructure. In this topology, the Signal Plane and Analysis Plane are deployed on-premise; model weights and rule updates are delivered via a signed update package to an air-gapped internal registry. The Decision Plane operates entirely within the client's environment; no decision data or feature data is transmitted to the platform's cloud infrastructure.

Federated learning is available as an optional component in the hybrid deployment, allowing the platform to train improved shared models using gradient updates derived from the client's data — without the underlying data ever leaving the client's environment. Federated participation is strictly opt-in and governed by a separate data usage agreement.

The following roadmap reflects planned development as of May 2026. All timelines are indicative; institutional clients with specific dependency requirements should engage the product team directly to discuss priority alignment.

The following table enumerates the primary signals collected by the QUORUM platform, organized by category. Feature count per category represents the number of derived features produced from the raw signal source in the production feature vector.

The following table summarizes the QUORUM REST API endpoints. Full API documentation, including schema definitions and error code references, is available in the platform's developer portal under a separate distribution agreement.

All endpoints accept and return application/json. Rate limits apply per API key: 10,000 requests per minute for /v1/evaluate; 1,000 requests per minute for all other endpoints. Rate limit headers (X-RateLimit-Remaining, X-RateLimit-Reset) are included in all responses. Institutional clients with throughput requirements exceeding the default limits should engage their account team to discuss dedicated rate limit configurations.

The following table defines the three canonical QUORUM deployment configurations. These configurations map directly to the platform's commercial tiers and are designed to align the technical decision-making of the CTO with the commercial evaluation of the CFO. All configurations run identical engine logic; differentiation is in cluster topology, data residency, and federated learning participation.