QShield — Fraud & Risk

QShield — Fraud & Risk

QShield is the fraud and risk decisioning engine inside the QoinPay Enterprise suite. It sits in the authorization path of every payment and payout, evaluates each transaction against a deterministic rule set, and returns an actionable verdict — approve, review, or decline — before money moves. QShield is built for institutions that need to block fraud at the point of decision, not merely log it after the fact, and to do so entirely on their own infrastructure with no transaction data leaving the perimeter.

Capabilities

QShield's core is a synchronous rules engine. Rules are expressed as ordered conditions over a normalized transaction envelope (amount, currency, MCC, channel, subject identifiers, device and network attributes, historical aggregates). Each rule carries an action and a weight, and the engine short-circuits on the first hard-decline or evaluates the full set to produce a cumulative risk score, depending on how the policy is configured.

Key capabilities:

• Screening — subjects (customers, cards, accounts, beneficiaries, IBANs) are screened against internal deny/allow lists and imported sanctions or watch lists. Matches are fuzzy where configured, with a tunable similarity threshold to balance recall against false positives.
• Velocity and limits — sliding-window counters track events per subject, per instrument, per device, and per IP over configurable intervals. Limits can be absolute (amount, count) or relative (velocity spikes versus a subject's own baseline).
• Block, not just log — every rule outcome is enforceable. A decline verdict stops the transaction in-line; a review verdict quarantines it and opens a case; an approve verdict passes it through with the score attached for downstream audit.
• Case management — reviewable transactions and manual escalations become cases in a work queue. Analysts see the full evaluation trace (which rules fired, with what values), can add notes, reassign, and resolve with a coded disposition that feeds back into list and baseline updates.

Every decision is written to an immutable, append-only decision log with the full rule trace, so audits and disputes can reconstruct exactly why a transaction was allowed or blocked.

Rules and the evaluation trace

Rules are versioned and can be edited in a staging policy, tested against replayed historical traffic, and promoted atomically. A minimal rule looks like this:

rule: high_value_new_beneficiary
when:
  - amount.gt: 5000
  - beneficiary.age_days.lt: 7
action: review
weight: 40
reason: "Large payout to recently added beneficiary"

At runtime the engine returns a structured verdict that both the payment flow and the case queue consume:

{
  "decision": "review",
  "score": 72,
  "rules_fired": ["high_value_new_beneficiary", "velocity_ip_1h"],
  "case_id": "CASE-2026-004512"
}

Integration

QShield is invoked over the suite's REST surface at /api/v1, or in-process by QoinPay payment products via a native call so no round trip leaves the host. Asynchronous events — a case opened, a decision reversed, a list updated — are delivered as signed webhooks so external ledgers and SIEM tooling stay in sync. See the API reference for the request envelope and signature verification.

Editions

• Standard — synchronous rules engine, velocity/limits, internal deny/allow lists, decision log, and a single analyst case queue. Suitable for a single business unit or processing entity.
• Advanced — adds multi-list screening with fuzzy matching and scheduled list imports, per-subject behavioral baselines, staged-policy testing against replayed traffic, multi-queue case routing with SLAs, and the full signed-webhook event stream.

Editions are unlocked by the license key; no reinstallation is required to move from Standard to Advanced.

Sizing

QShield decisioning is CPU- and memory-bound on the counter store rather than on raw storage. As a planning baseline:

• Up to ~50 TPS: 4 vCPU / 8 GB on the application tier, counters held in the primary MariaDB instance.
• 50–300 TPS: 8 vCPU / 16 GB, with velocity counters moved to a dedicated in-memory store and MariaDB provisioned for the decision-log write rate.
• 300+ TPS: horizontally scale application nodes behind the load balancer; keep the counter store and decision log on separate, appropriately provisioned volumes.

Provision decision-log storage for your retention policy — typically 1–3 KB per decision including the rule trace. High-review-rate deployments should size the case database for concurrent analyst load.

Licensing

QShield is perpetually licensed per production instance, with the enabled edition and any capacity tier encoded in the activation key. Software Subscription & Support (SnS) is included for the first year and covers rule-pack updates, screening-list connector updates, and product fixes. Non-production instances (DR, staging) are licensed at a reduced tier. See the licensing overview for the Quote → Order → Entitlement → License key → Activation lifecycle.

Deployment security

QShield processes highly sensitive transaction and subject data, so treat it as a Tier-1 component:

• Run the decisioning service on the internal application tier only; never expose /api/v1 fraud endpoints to the public internet without an authenticated gateway.
• Restrict database credentials to the QShield schema, and keep the append-only decision log on storage where deletes and updates are denied at the grant level.
• Encrypt screening lists and imported watch data at rest; rotate the API keys and webhook signing secrets on the schedule your security policy mandates.
• Analyst access to the case queue must be role-scoped, and every disposition is attributed to a named operator in the audit trail.

For tokenized handling of card and account data referenced in rules, pair QShield with QVault so raw PANs never enter the fraud schema.