04 · Fraud

Rules-first.
Explainable by design.

Evaluate payment events in real time with versioned rules, enriched context, and deterministic outcomes — then apply the same policy vocabulary across gateway (CNP) and switch (POS).

Built forRisk, operations, and compliance teams that must defend decisions to auditors — not black-box score buyers

Book a technical walkthrough Request sandbox

Decision style

Rules-first with reason codes

Rails

Gateway CNP · Switch POS dual-rail

Change control

Shadow mode · maker-checker · versioning

02 · Problem

What buyers are solving

Framed for Risk, operations, and compliance teams that must defend decisions to auditors — not black-box score buyers — not generic payment pain.

Black-box scores fail audits

When disputes or regulators ask why, teams cannot reconstruct the decision path.

CNP and POS policies drift

Online and in-store teams maintain separate tools with conflicting thresholds.

Rule changes are all-or-nothing

Without shadow mode, every promotion risks false-positive spikes in production.

03 · Flow

How it works

Ingest event
Authorization, auth advice, or gateway session signals.
Enrich
Velocity, lists, BIN/MCC, geo, device, and custom attributes.
Decide
Deterministic rules with explicit outcomes and reason codes.
Orchestrate
Allow, decline, or step-up with downstream hooks.
Review
Analyst queues with full trace to rule versions.

fraud · event_4QH8 · cnp

score 0.72 → step-up

Decision breakdown

Base risk · CNP

+ 0.25

BIN tier · medium

+ 0.15

Velocity 5m > 4x

+ 0.20

Device · new

+ 0.12

Allowlist hit

− 0.00

OUTCOME · STEP-UP

Send to 3DS2 challenge before authorization.

rule_v37 · explained

04 · Capabilities

Core capabilities

Each capability names a concrete mechanism — not a marketing adjective.

Rules engine

Deterministic evaluation with explicit allow / decline / step-up outcomes and reason codes on every decision.

Dual-rail hooks

Same policy surface evaluates gateway CNP events and switch POS authorizations.

Velocity & lists

Counters, allow/block lists, BIN & MCC tiers, country controls — first-class rule atoms.

Device & geo signals

Enrichment attributes available to rules without requiring a separate opaque score to be the only outcome.

Shadow mode

New rule versions emit decisions without enforcing them until promoted — compare false-positive impact first.

Maker-checker promotion

Rule authors and approvers are segregated; promotions are versioned with reason codes.

Assisted rule suggestions

Optional AI-assisted suggestions propose rule candidates or threshold tweaks for analyst approval — never silent auto-deploy to production.

Review queues

Analyst workbenches with full evidence export for disputes and partner review.

Positioning

Where this sits vs alternatives

Build in-house

You get versioning, dual-rail hooks, and shadow promotion without owning a rules platform from scratch.

Local incumbent rules in the switch

Switch-embedded rules rarely share vocabulary with CNP. Fraud Engine centralizes both rails.

Global ML-first fraud SaaS

Many global tools lead with opaque scores. Flagship leads with explainable rules; AI assists analysts, it does not replace the audit trail.

05 · Architecture

Architecture and deployment

Events enter from gateway or switch, enrich, evaluate, and return an action plus evidence — case tools can sit beside.

Event sourcesGateway sessions · Switch authorizations

EnrichmentVelocity, lists, BIN/MCC, device, geo

DecisioningVersioned rules · shadow · promote

Actions & evidenceAllow/decline/step-up · review queues · exports

Deployment options

SaaS beside rails

Fraud control plane evaluating events from Flagship Gateway/Switch within a programme latency budget.

Private deployment

For banks that require fraud data on-prem — dedicated or private-cloud deployment.

Hybrid signals

On-prem enrichment with cloud rule management — supported hybrid pattern for regulated estates.

HA on the decision path; fail-open vs fail-closed posture is documented at go-live.
PII in fraud payloads follows programme residency controls; minimisation applies by default.
Fail behavior under dependency outage is agreed per programme; default recommendation is fail-closed on high-risk paths.

06 · Integration

Integration experience

Evaluate via API from gateway/switch hooks or stand-alone. Example hosts are illustrative.

Illustrative example — not a live endpoint

Request

POST https://api.flagship.example/v1/fraud/evaluate
Authorization: Bearer $FLAGSHIP_TOKEN
Content-Type: application/json { "transaction_id": "txn_1", "rail": "gateway", "amount": { "value": "499.00", "currency": "EGP" }, "signals": ["velocity", "device", "bin_tier"]
}

Response

{ "decision": "step_up", "reason_codes": ["VEL_01", "DEV_NEW"], "rule_version": "rv_14", "shadow": false
}

SDKs & client libraries

REST evaluate API; TypeScript / Node and language packs at onboardingREST evaluate + webhooks for async reviewRule export as JSON and CSV for audit and backup

Sandbox

Sandbox tenants include sample rulesets, shadow mode, and sample datasets. Request via contact.

Typical integration timeline

Week 1Event mapping and baseline rules in the first week
Week 2–4Shadow parallel run vs current tool
PromoteMaker-checker go-live on selected segments

Integrations

GatewaySwitchDevice signals

07 · Security

Security and compliance

Fraud payloads are sensitive — minimization and access control are mandatory design constraints.

Segregation of duties

Rule authors vs approvers; overrides are audited.

Immutable promotions

Rule version history retained for regulator and partner review.

PII minimization

Hooks to limit sensitive attributes shared with any third-party scoring partners enabled for your programme.

08 · Commercial

Pricing orientation

Fraud is usually priced on evaluated events plus optional review seats. Numbers on request.

Monthly evaluations

Events scored across rails.

Rails in scope

Gateway only, switch only, or dual-rail.

Analyst seats

Review queue users.

Assisted suggestions

Whether AI-assisted rule suggestions are enabled.

Commercials follow after a shadow-mode pilot design.

09 · FAQ

FAQ

Deal-killing objections, answered plainly.

Is this a black-box score?

No. The product direction is explainable, rule-first decisions with traceability. Scores can exist as inputs; they are not the only story.

Can we run shadow rules?

Yes. Shadow mode is part of the rollout vocabulary before enforcement.

Does it replace our case management tool?

It focuses on decisioning and evidence export; case management tools can sit beside it.

Will AI auto-block customers?

No. Assisted suggestions require human approval before production rule changes. Runtime decisions follow the published ruleset.

Can we keep our existing lists?

Allow/block lists are first-class — CSV and JSON import formats are scoped at onboarding.

What happens if the fraud service is down?

Fail-open vs fail-closed is a programme decision documented at go-live; we typically recommend fail-closed on high-risk authorisations.

Shadow your current tool before cutting over

Bring sample events and your top five rules. We will design a shadow parallel run — not a model pitch deck.