Redis Real-Time Decisioning Demo | Credit Card Fraud Detection

Stage 1: The Architecture

Sub-20ms authorization decisioning for credit card fraud detection

Authorization fraud cannot wait for batch scoring. Card state, spending history, geo velocity, merchant risk, and device intelligence must converge before the network receives the issuer response. Redis sits between the issuer's existing systems and the authorization path, assembling real-time card context for every transaction.

Data Sources

Issuer Core Banking

Account status, credit limit, cardholder profile, card standing

Transaction History

Spending patterns, merchant categories, velocity, prior disputes

Merchant Risk Database

Category risk, geo flags, fraud association scores

Device + 3DS Intelligence

Device fingerprint, 3DS challenge history, behavioral biometrics

Kafka / Auth Event Stream

Real-time authorization events, settlement, dispute feeds

Ingest Layer

RDI

Syncs cardholder, account, and transaction state

Redis Feature Form

Serves velocity, spending, and fraud features online

Unified Context Layer

Redis RAM

Hot authorization path, active dispute flags, velocity counters

Redis Flex

Warm transaction history, merchant patterns, and fraud embeddings

Feature Store

Velocity, spending deviation, merchant risk, behavioral features

Redis Context Retriever

Assembles the Transaction 360 — card state, spending history, and risk signals — and exposes it as structured MCP tools for the decision engine

Decision Engine

Velocity Rules Engine

Transaction rate, amount, and geo constraint rules

ML Fraud Scorer

Behavioral deviation, typology pattern matching

Risk Arbitration

Issuer policy, threshold, and confidence scoring

Redis Search

Typology vector matching across known fraud patterns

Output Actions

Approve

Low-risk transaction proceeds to settlement

Decline

High-risk transaction blocked at the network

3DS Step-Up

Challenge required before authorization completes

Case Queue

Transaction flagged for analyst review with full context

Decision Target

<20 ms

Primary Goal

Fraud loss + approval rate

Redis Role

Real-time card context

Stage 2: Auth Event

A card-present transaction triggers an impossible-travel fraud signal

Elena Vasquez purchased coffee in Chicago, IL two hours ago. Now a $2,150 card-present transaction appears at an electronics retailer in Miami, FL. The same physical card cannot be in both cities. The authorization window is under 100ms — the fraud decision has to happen before the network confirms the charge.

Authorization Request

Elena Vasquez

Visa ending 4821 | 4-year cardholder | Chicago, IL primary location

HIGH FRAUD RISK

Eventauthorization_request

MerchantElectronics Emporium, Miami, FL

Amount$2,150.00

Transaction typeCard-present (chip)

Last verified purchase$8.40 coffee, Chicago, IL — 2.1 hours ago

Geo velocityChicago → Miami in 2.1 hours (impossible travel)

Prior dispute historyNone — first suspicious event on this card

Why This Moment Matters

The processor sees a card-present transaction for $2,150 in Miami two hours after the same cardholder verified a purchase in Chicago. The physics make simultaneous presence impossible. The authorization window is under 100ms.

This is where Redis becomes much more than cache. The value is not page speed. The value is unified card context fast enough to catch the fraud signal inside the authorization window before the network confirms the charge.

Stage 3: Ingest

Card, transaction, and risk systems flow into Redis

RDI synchronizes cardholder, account, and transaction state. Redis Feature Form serves the online features used by the fraud decision stack. Redis becomes the live working set for card authorization decisions without waiting for slow cross-system joins.

Source Systems → Redis

BANK

Issuer Core Banking

Account status, credit limit, cardholder profile, card standing

→

TXN

Transaction History

Prior purchases, merchant categories, geo patterns, dispute records

→

MRCH

Merchant Risk Database

Category risk, geo flags, fraud association scores

→

DEV

Device + 3DS Intelligence

Device fingerprint, 3DS challenge history, behavioral biometrics

→

KFK

Kafka / Auth Event Stream

Real-time authorization events, settlement, and dispute feeds

→

Pipeline Status

Cardholder state syncContinuous

Transaction event feedStreaming

Merchant risk syncSub-second

Redis Feature Form parity100%

Velocity counter pathServed from Redis

Decision modeInline authorization

Stage 4: Context

Redis assembles the live card picture

The authorization decision needs card state, transaction history, geo velocity, merchant risk, and device confidence in the same path. That is operational context, not a single fraud score.

Redis RAMRedis FlexRedis Context Retriever

Durable Card Context

Cardholder home geoChicago, IL — consistent 4-year baseline

Typical spend range$15–$400 per transaction, grocery, dining, travel

Last verified merchantCoffee shop, Chicago, IL — 2.1 hours ago

Geo velocity violationSame card cannot be in Miami and Chicago simultaneously

High-value electronicsOutside established spending pattern

Dispute historyNone — first suspicious event on this card

Live Auth Context

Transaction amount$2,150 — 5x above typical transaction

Merchant categoryElectronics — not a prior category for this cardholder

Device fingerprintNo prior 3DS session on this device

Auth timeFriday 3:47 PM — peak fraud window for card-present

Issuer velocity windowFirst high-value transaction this billing cycle

Current action neededDecline or step up — not auto-approve

Context signal: Redis Context Retriever assembles the Transaction 360 — card state, spending history, and risk signals — so the decision engine has exactly what it needs. Geo velocity violation and behavioral deviation converge on the same authorization outcome.

Stage 5: Feature Serving

Card risk features hydrate in milliseconds

Redis Feature Form serves the online features that support fraud authorization: geo velocity, spending deviation, merchant risk, card maturity, device confidence, and typology pattern matching via Redis Search.

geo_velocity_score

Abnormality of cardholder location shift relative to transaction timing

0.980.3 ms

spending_deviation_score

Distance of current transaction from established spend baseline

0.910.4 ms

merchant_risk_score

Risk inferred from merchant category and fraud association history

0.740.3 ms

card_maturity_score

How established and behaviorally predictable the card account appears

0.880.2 ms

device_3ds_confidence

Confidence in device identity based on prior 3DS challenge history

0.110.4 ms

typology_match_score

Similarity to known card-present fraud patterns via Redis Search

0.931.1 ms

Feature Serving Performance

Features Hydrated

P99 Lookup

2.1 ms

Train / Serve Parity

100%

Stage 6: Decision

Approve, decline, step up, or queue — one action wins

The authorization engine evaluates the available actions using unified card context. This is not a generic fraud score threshold. It is an action decision grounded in live transaction context assembled by Redis.

#1 Winning Action

DECLINE

Transaction blocked — impossible travel confirmed

Geo velocity violation plus spending deviation make this the only defensible issuer response

The card cannot be in Chicago and Miami simultaneously. Combined with typology match, decline is the clear action.

Action confidence0.96

#2 Escalate

3DS STEP-UP

Challenge required before authorization completes

Valid secondary if geo signal alone were less extreme

Typology match score and zero device history make this insufficient protection on its own for this event.

Action confidence0.74

Suppressed

AUTO-APPROVE

Proceed to settlement

Suppressed — approval exposes the issuer to full chargeback liability

Every feature in the live path points the same direction. This is exactly the action a fragmented stack is more likely to get wrong.

Action confidence0.04

Stage 7: Business Impact

The value is fraud blocked before chargeback, with fewer false positives

Inline card context means the processor stops more fraud before exposure, protects the issuer from chargeback liability, and avoids blunt over-blocking that damages legitimate cardholder relationships.

Operational Value

Fraud loss preventionTransaction blocked before chargeback exposure

False-positive controlPattern confidence high enough to decline safely

Cardholder protectionCompromise detected without waiting for dispute

Issuer liabilityChargeback avoided by inline real-time decision

Network standingDispute rate protected with precise, evidence-based decline

Per-Event Outcome

late detect

post-settlement
chargeback path

→

blocked

inline authorization
no exposure

Stage 8: Outcome

Same card network. Different authorization quality.

Without Redis, the processor relies on delayed signals and post-settlement detection. With Redis, the live card context is assembled inline so the issuer can decline confidently before the charge settles.

Fragmented Authorization

NOVAPAY

Auth request for Elena

Current state

Siloed checks

Delayed signals, post-settlement catch

late

detection

missed

fraud

exposed

chargeback

Redis-Powered Authorization

NOVAPAY

Auth request for Elena

Winning action

DECLINE

Transaction 360 assembled in Redis

Why this wins

Geo velocity + spending deviation + typology converge

The authorization path is grounded in live card context, not a single isolated score.

96%

confidence

<20ms

inline

blocked

fraud

Stage 9: Architecture Recap

Redis becomes mission-critical decision infrastructure, not just cache

Issuer banking, transaction history, merchant risk, and device intelligence systems stay in place. Redis becomes the operational context layer that makes those systems usable in the live authorization path.

Data Sources

Issuer Core Banking

Account status, credit limit, cardholder profile, card standing

Transaction History

Spending patterns, merchant categories, velocity, prior disputes

Merchant Risk Database

Category risk, geo flags, fraud association scores

Device + 3DS Intelligence

Device fingerprint, 3DS challenge history, behavioral biometrics

Kafka / Auth Event Stream

Real-time authorization events, settlement, dispute feeds

Ingest Layer

RDI

Syncs cardholder, account, and transaction state

Redis Feature Form

Serves velocity, spending, and fraud features online

Unified Context Layer

Redis RAM

Hot authorization path, active dispute flags, velocity counters

Redis Flex

Warm transaction history, merchant patterns, and fraud embeddings

Feature Store

Velocity, spending deviation, merchant risk, behavioral features

Redis Context Retriever

Assembles the Transaction 360 — card state, spending history, and risk signals — and exposes it as structured MCP tools for the decision engine

Decision Engine

Velocity Rules Engine

Transaction rate, amount, and geo constraint rules

ML Fraud Scorer

Behavioral deviation, typology pattern matching

Risk Arbitration

Issuer policy, threshold, and confidence scoring

Redis Search

Typology vector matching across known fraud patterns

Output Actions

Approve

Low-risk transaction proceeds to settlement

Decline

High-risk transaction blocked at the network

3DS Step-Up

Challenge required before authorization completes

Case Queue

Transaction flagged for analyst review with full context

Decision Target

<20 ms

Primary Goal

Fraud loss + approval rate

Redis Role

Real-time card context