Verifex Shield

Executive Summary

CİBPAY already defined what good fraud control looks like. Verifex Shield is the system that runs it.

On 1 June 2026, CİBPAY approved a fraud management procedure and a set of 27 detection rules. Those documents describe, in policy terms, a complete fraud-prevention system — graded responses, device and transaction monitoring, blacklisting, investigation workflow, and Central Bank reporting. What they do not yet have is the engine that executes them in real time.

Verifex Shield is that engine. It is a fraud-decisioning API that screens every transaction and session against your rules, returns a verdict in under 50 milliseconds, and stores a tamper-evident record of every decision. It is built on the same infrastructure as Verifex Core — our sanctions screening and evidence platform — so a single check can cover both fraud risk and regulatory screening of the counterparty.

The Problem — In CİBPAY's Own Terms

This proposal does not begin with generic fraud statistics. It begins with your documents.

Your fraud procedure lists the threats CİBPAY faces precisely: lost and stolen cards, account and card-data takeover, phishing, social engineering, chargeback abuse, malware, and internal fraud. Your rules file then defines 27 concrete detection rules across transaction and device behaviour. This is a strong foundation — more structured than most companies your size produce.

But a policy document and a rules list are not a running system. Three gaps stand between them and live fraud prevention:

• Description, not measurement. Indicators like "transactions higher than normal" or "transactions at night hours" have no threshold, window, or data field a machine can evaluate.
• No automated response. The procedure defines what people do after fraud is suspected. It does not define what the system does in the millisecond before a human is involved.
• No proof layer. When the Central Bank or an auditor asks what was screened, when, and why a decision was made — there is currently no automatic, tamper-evident record to show them.

Shield closes all three.

What Verifex Shield Is

Shield is a real-time fraud-decisioning API. CIBIM's backend sends it a transaction or session event; Shield evaluates your rules, enriches with identity and device signals, and returns a verdict and a recommended action — plus an Evidence Capsule, a tamper-evident record of exactly what was checked and why.

It is built as ten cooperating layers:

Shield and Verifex Core — one platform

Shield does not stand alone. It runs on the same infrastructure as Verifex Core, our sanctions and PEP screening engine. That means a single transaction check can ask two questions at once: is this behaviour fraudulent? (Shield) and is the counterparty sanctioned or politically exposed? (Core). No standalone fraud vendor can answer the second question — it is a structural advantage unique to Verifex.

📋 What We Added to Your Documents

Verifex reviewed both files CİBPAY shared — the Fraud Management Procedure and the 27-rule Anti-Fraud Rules sheet. We did not rewrite your signed procedure; it is your approved governance document. Instead we built the specification layer that makes it enforceable. Here is exactly what was added, point by point.

How It Works — Integration Model

Integration is deliberately light. CIBIM's backend adds a single call before processing a transaction. Shield runs on Verifex infrastructure; nothing is deployed on your side.

The entire integration on CİBPAY's side

// In CIBIM's backend — before processing any transfer
async function processTransfer(req) {

  // 1 — Call Shield BEFORE executing the transfer
  const check = await verifexShield.screenTransaction({
    customer_id:      req.userId,
    amount:           req.amount,
    currency:         "AZN",
    receiver_account: req.receiverId,
    receiver_name:    req.receiverName,
    device_id:        req.headers["x-device-id"],
    ip:               req.ip,
    timestamp:        new Date().toISOString()
  });

  // 2 — Act on the verdict
  if (check.verdict === "block")    return decline(check.capsule_id);
  if (check.verdict === "escalate") return stepUpAuth(req.userId);
  if (check.verdict === "delay")    return holdAndNotify(check.capsule_id);
  if (check.verdict === "review")   await flagForReview(check.capsule_id);

  // 3 — Proceed
  return await executeTransfer(req);
}

The Detection Pipeline

Every event flows through a six-stage pipeline. The blacklist check runs first, so a known-bad device is blocked in under 10 milliseconds without evaluating a single rule.

A rule, in code

Rules are configurable records, not hard-coded logic — so CİBPAY can tune a threshold without a new deployment. State (velocity counters, session tracking) lives in Redis with time-based expiry.

// Velocity rule — transaction count in a sliding window
class TransactionCountRule {
  async evaluate(ctx) {
    const key   = `txn_count:${ctx.customerId}:${windowKey}`;
    const count = await redis.incr(key);
    await redis.expire(key, this.params.windowSeconds);

    if (count >= this.params.threshold) {
      return { triggered: true, risk: this.baseRiskScore,
               reason: `${count} txns in ${this.params.windowLabel}` };
    }
    return { triggered: false, risk: 0 };
  }
}

The 27 Rules — Full Reference

Your complete rule set, restructured with verdict mapping and priority. NEW rows are the six rules Verifex proposes to close the gaps described above. Best viewed full-screen on desktop.

Transaction Rules

Device & Session Rules

Recipient & Sanctions Rules ALL NEW

Scoring & Verdicts

When several rules fire on one event, Shield aggregates them: the highest single rule score, plus five points for each additional rule that triggered, capped at 100. A confirmed sanctions match or a biometric failure forces a block regardless of the number.

Worked example — a card-testing burst trips TXN_03 (90), TXN_04 (90), TXN_09 (80), TXN_10 (90) and DEV_14 (95): highest 95, plus four × 5 = 115, capped at 100 → Block.

Lifecycle state vs final outcome — a deliberate design choice

Informed by technical benchmarking of leading platforms, Shield separates two concepts that simpler APIs collapse into one. Status tracks where a decision is in its lifecycle. Outcome is the final closed verdict. This matters for mid-flight cases where a transaction is under review but no final decision has been made yet — a critical distinction for case management and audit reporting.

// In-flight — review in progress, outcome not yet set
{
  "status":  "waiting_review",
  "outcome": null,
  "risk_score": 87,
  "capsule_id": "frd_cap_0391"
}

// Closed — lifecycle complete, outcome recorded
{
  "status":  "completed",
  "outcome": "block",
  "risk_score": 100,
  "capsule_id": "frd_cap_0392"
}

Lifecycle states: running · waiting_review · pending_step_up · completed · error  ·  Final outcomes: block · escalate · review · delay · clear

How Shield compares to Sardine

Sardine — the category benchmark for fintech fraud APIs — returns a primary level field (low | medium | high | very_high) as its main signal, leaving the action decision to the integrator. Shield returns an explicit recommended_action, telling CIBIM's backend exactly what to do. For a payment institution processing thousands of transactions daily, that removes an entire decisioning layer from your engineering team.

Real-World Scenarios

① Normal transfer — zero friction

A user sends 50 AZN to a friend. No rule trips; risk score 8; verdict clear in 45 ms. The user sees "Transfer successful." Shield ran invisibly.

② Card-testing attack — multi-rule block 🔴

A bot runs 15 small transactions in 8 minutes from one device. By the fourth call, five rules fire together (velocity, repeated-amount, smurfing, high-velocity, multi-instrument). Aggregated score hits 100 → block. Shield auto-blacklists the device and IP; transactions 5–15 are blocked in under 10 ms each, before any rule even runs.

// Shield response on transaction #4
{
  "verdict": "block",
  "risk_score": 100,
  "rules_triggered": ["TXN_03","TXN_04","TXN_09","TXN_10","DEV_14"],
  "recommended_action": "block",
  "reasons": ["15 transactions in 8 minutes",
              "Multiple identical amounts",
              "Multiple payment instruments, one device"],
  "capsule_id": "frd_cap_0287"
}

③ Account takeover — the Delay tier 🔵

A fraudster phishes a user's credentials and logs in from Romania (the real user is in Baku). New device, new country, third new device this week — Shield returns escalate, and CİBPAY triggers SMS step-up. The fraudster has no access to the real phone, so it fails. Even if step-up were bypassed, the first transfer to a new recipient from a new device triggers delay — the transfer is held and the real customer is notified, giving them time to stop it. Two independent layers, both catching the same attack.

④ Sanctioned counterparty — the Verifex advantage 🔴

A legitimate user unknowingly sends 200 AZN to a business that sits on the EU sanctions list. Shield's SAN_01 rule calls Verifex Core, which matches the recipient against the EU Consolidated list at 87% confidence → block, with both a fraud capsule and a sanctions capsule retained for audit.

No standalone fraud vendor can produce this slide. It requires a sanctions data layer sitting inside the same check — which only Verifex has.

What Makes Shield Different

Where global vendors' assumptions break for your market

Technical benchmarking of Sardine, Unit21, and Alloy confirms a consistent pattern: all three are built on Western data infrastructure that does not transfer cleanly to Azerbaijan or West Africa.

Benchmarked Against the Best

Shield's design was benchmarked against three category leaders through independent technical research. Not marketing claims — actual API teardowns of verified public documentation, with confidence levels assigned to every finding.

Visa Decision Manager — design inspiration

Visa Decision Manager draws ML insight from tens of billions of annual transactions. We do not claim to match its data scale. We adopt the design patterns its two decades of production use validated:

• Replay / "what-if" testing — test a rule change against historical events before deploying it live. Shield's rule-tuning layer follows this pattern exactly.
• Rules-suggestion thinking — the engine recommends rules from historical patterns. Shield's roadmap applies the same to your accumulated Evidence Capsules.
• A clear verdict taxonomy — Visa's approve / challenge / decline model directly informed Shield's five-tier structure.

Sardine — API design benchmark

Sardine is the fintech fraud API category leader, used by neobanks and crypto platforms globally. Technical teardown of its public API confirmed its verdict model, signal taxonomy, and schema patterns. Shield adopts Sardine's per-signal reasons[] breakdown and builds on it — returning explicit recommended actions where Sardine returns only a risk level and leaves the decision to you.

// Sardine returns a risk level — you decide what to do
{ "level": "high", "customer": { "score": 87 } }

// Shield returns what to do — plus the evidence behind it
{ "outcome": "block", "risk_score": 87,
  "rules_triggered": ["DEV_12", "DEV_16"],
  "reasons": ["ATO sequence: new device + profile change + transaction",
              "First transfer to new recipient from untrusted device"],
  "capsule_id": "frd_cap_0391" }

Alloy — workflow architecture benchmark

Alloy is the identity and risk orchestration standard for fintechs and banks. Its API teardown revealed two design patterns Shield directly adopts:

• Schema discovery endpoint — GET /events/schema lets integrators discover the exact contract for each event type dynamically, eliminating hard-coded assumptions and reducing integration friction when schemas evolve.
• Lifecycle state separate from final outcome — Alloy's application states (running | waiting_review | pending_step_up | completed) are kept separate from the final decision. Shield adopts this pattern in its status + outcome separation shown above.

Unit21 — operational benchmark

Unit21's public materials confirmed two concrete targets for Shield: a sub-250ms real-time decisioning SLA (Shield achieves under 50ms on the clean path), and the alert → case → investigation → regulatory filing workflow that Shield's case management layer mirrors — adapted for the Central Bank of Azerbaijan rather than FinCEN.

Data, Security & Residency

What flows to Shield

Transaction and session fields: customer and device identifiers, amount, IP, and optional geolocation. Shield returns a verdict and an Evidence Capsule ID.

Security

• TLS 1.3 in transit; AES-256 for stored data.
• API keys SHA-256 hashed; HMAC-signed webhooks.
• Evidence Capsules append-only at the database level — no update or delete possible.

Data residency — handled honestly

Shield currently runs on Verifex infrastructure in Germany. Azerbaijani data-protection rules may require personal data of citizens to be handled locally. We propose a two-step path:

• Now — pseudonymization. CİBPAY hashes customer, device and IP identifiers before sending. The rules still work (they compare hashed values), and Verifex never stores raw personal data.
• Later — local deployment. When volume justifies it, a Shield instance can run on a VPS in Baku, with AZ clients pointed to a local endpoint.

If Shield is briefly unavailable

CİBPAY chooses the failure mode. For a payment app we recommend fail-open: process the transaction with a review flag rather than block all transfers while the fraud service recovers. The choice is yours to document for your regulator.

Architecture & Scale

Shield reuses Verifex's production stack: Node.js + Fastify API, PostgreSQL 16 (append-only audit triggers), Redis 7 (counters, session state, blacklist cache), BullMQ for async work — on an IONOS VPS with PM2 cluster mode.

Scale headroom at CİBPAY's load

Modelled at 10,000 daily active users × 3 transactions/day plus session events — roughly 50,000 calls/day:

The conclusion: Shield handles CİBPAY's load with very large headroom on existing infrastructure. No new servers are required to begin.

Figures are modelled estimates for planning, not a performance guarantee; real numbers will be confirmed in a pilot.

Third-Party Cost Stack — and How Shield Reduces It

Modern fraud detection draws on external data signals. The gold-standard enterprise platforms charge accordingly. Shield's architecture is designed to keep that external spend low — and to replace much of it with first-party signals CİBPAY already owns.

What the market charges

*Indicative ranges from public sources and typical market pricing — not quotes. Real figures require direct negotiation and may differ.

How Shield reduces the external bill

• 13 of 27 rules need no third party at all. Velocity, smurfing, failed-logins, concurrent sessions and more run entirely on Redis and your own data — zero per-call cost.
• SIMA replaces identity lookups. Because your customers are already SIMA-verified, Shield does not pay an external vendor to guess whether they are real. Government KYC beats email-footprint scoring — and it is free to you.
• Selective enrichment, not blanket calls. Paid device-intelligence lookups fire only on new or already-suspicious events — roughly 15–20% of sessions — instead of every event. Combined with 24-hour caching, this cuts paid lookups by up to 80%.
• MaxMind self-hosted. Geolocation and impossible-travel run from a local database, at near-zero marginal cost.

Implementation Plan