Real-Time Decisioning Demo | Player Verification and Fraud Risk Triage
Pipeline<20ms
1 / 9
1
Architecture
2
Risk Event
3
Ingest
4
Context
5
Feature Serving
6
Decision
7
Business Impact
8
Outcome
9
Architecture Recap
Stage 1: The Architecture
Mission-critical decisioning for trust, verification, and fraud triage
Know Your Customer (KYC) — the process of verifying a player's identity and assessing their ongoing risk — and Anti-Money Laundering (AML) — the obligation to detect and report suspicious financial behavior — are not batch reporting problems in the player moment. Identity, device, wallet, deposit behavior, verification providers, case history, and transaction streams flow through RDI and Redis Feature Form into Redis. Redis serves the live operational context needed to approve, step up, restrict, or review before the risk event propagates.
Data Sources

Account + KYC

Identity, documents, verification steps

Wallet + Payments

Deposits, withdrawals, rails, velocity

Sportsbook + Casino

Bet behavior, session pattern, product exposure

Device + Risk Vendors

Fingerprint, IP, geolocation, anomaly signals

Kafka / Case Feed

Transaction stream, alerts, prior reviews

Ingest Layer

RDI

Syncs account, wallet, case, and verification state

Redis Feature Form

Serves fraud, AML, velocity, and risk features online

Unified Context Layer

Redis RAM

Hot transaction path, active alert state, case step-up context

Redis Flex

Warm case history, device graph, transaction history, and risk embeddings

Feature Store

Velocity, anomaly, network risk, verification confidence

Redis Context Retriever

Assembles the Account 360 — identity state, transaction history, and risk signals — and exposes it as structured MCP tools for the decision engine

Decision Engine

Triage Rules

Thresholds, jurisdiction, product, payment policies

Risk Ranker

Fraud, AML, and confidence weighting

Network Graph Logic

Links account, device, wallet, and behavior clusters

Action Arbitration

Approve, step up, restrict, or review

Output Actions

Approve

Low-risk session continues

Step Up

Request more verification or payment challenge

Restrict

Pause deposit, withdrawal, or bonus path

Manual Review

Open case with full context attached

Decision Target
<20 ms
Primary Goal
Protect trust + limit loss
Redis Role
Operational risk context
Stage 2: Risk Event
A deposit attempt triggers a real-time triage decision
Diego attempts a high-value deposit after creating his account 40 minutes ago. He has passed light onboarding but not enhanced verification. The same device fingerprint is linked to two prior restricted accounts, and the payment instrument has unusual velocity across multiple accounts. The platform must decide immediately whether to approve, step up, or block.
High-Risk Deposit Attempt
DP
Diego Paredes
New account | 40 minutes old | Light KYC complete | High-value first deposit attempt
ELEVATED RISK
Eventdeposit_attempt
Deposit amountMXN 15,000
Account age40 minutes
Verification stateBasic onboarding complete only
Device fingerprintLinked to 2 prior restricted accounts
Payment velocityUnusual multi-account reuse pattern
Prior case historyNetwork adjacency to reviewed cluster
Why This Moment Matters
If the platform waits to understand this event later, it loses the advantage of acting in the live moment. The triage decision has to happen before the money path and risk exposure deepen.
This is where Redis becomes much more than cache. The value is not page speed. The value is a unified operational risk picture fast enough to drive the action now.
Stage 3: Ingest
Identity, wallet, device, and case systems flow into Redis
RDI synchronizes account, wallet, payment, case, and review state. Redis Feature Form serves the online features used by the triage stack. Redis becomes the live working set for risk and verification decisions.
Source Systems → Redis
KYC
Account + KYC Provider
Identity results, document checks, step-up state
→
WLT
Wallet + Payments
Deposit attempts, withdrawal state, rail history, instrument reuse
→
RISK
Device + Risk Vendors
Fingerprint, IP, geo, VPN / emulator / anomaly signals
→
CASE
Case Management
Prior reviews, outcomes, analyst notes, linked entities
→
KFK
Kafka / Redis Streams
Deposit, withdrawal, login, and gameplay event stream
→
Pipeline Status
Account + KYC syncContinuous
Payment event feedStreaming
Case history syncSub-second
Redis Feature Form parity100%
Graph query pathServed from Redis
Decision modeInline triage
Stage 4: Context
Redis assembles the live risk picture
The triage decision needs account state, payment state, device state, network adjacency, and case history in the same path. That is operational context, not simple scoring.
Redis RAMRedis FlexRedis Context Retriever
Durable Risk Context
Account historyVery new account with limited play history
Verification depthBasic onboarding only
Prior account links2 restricted accounts share device graph edge
Payment instrument behaviorSeen across multiple accounts in short window
Case historyPrior manual review cluster nearby
Jurisdiction controlsEnhanced checks required above threshold
Live Event Context
Deposit sizeHigh for a first-session deposit
Time from signup to deposit40 minutes
Geo / device confidenceModerate confidence only
Gameplay depth before depositMinimal
Bonus path exposureNot yet surfaced
Current action neededStep up or restrict, not auto-approve
Context signal: Redis Context Retriever assembles the Account 360 — identity state, transaction history, and risk signals — so the decision engine has exactly what it needs. This is not a low-risk account with a single suspicious feature. Multiple live and historical signals converge on the same triage outcome.
Stage 5: Feature Serving
Risk features hydrate in milliseconds
Redis Feature Form serves the online features that support fraud and AML triage: deposit velocity, account maturity, verification confidence, device-network adjacency, and case recurrence likelihood.
account_maturity_score
How established and behaviorally trustworthy the account appears
0.090.2 ms
deposit_velocity_score
Abnormality of transaction pattern relative to expected lifecycle
0.920.3 ms
device_graph_risk
Risk inferred from connections to known bad or reviewed entities
0.870.5 ms
verification_confidence
Confidence that current KYC level is sufficient for this action
0.280.3 ms
multi_account_payment_reuse
Strength of instrument reuse across connected accounts
0.900.4 ms
case_recurrence_likelihood
Likelihood this event should follow prior review paths
0.790.4 ms
Feature Serving Performance
Features Hydrated
151
P99 Lookup
2.4 ms
Train / Serve Parity
100%
Stage 6: Decision
Approve, step up, restrict, or review — one action wins
The triage engine evaluates the available actions using unified context. This is not a generic fraud score. It is an action decision grounded in live operational context.
#1 Winning Action
STEP UP + HOLD
Enhanced verification before deposit approval
Best action for trust protection and false-positive control
Enough converging risk to stop auto-approval, but better to step up than hard-block immediately.
Action confidence0.92
#2 Escalate
MANUAL REVIEW
Open case with full context attached
Valid fallback if enhanced verification fails or additional signals worsen
Important secondary action, but too costly as the default first move on every event like this.
Action confidence0.76
Suppressed
AUTO-APPROVE
Proceed normally
Suppressed because converging risk makes this unsafe
This is exactly the kind of action a fragmented stack is more likely to get wrong.
Action confidence0.12
Stage 7: Business Impact
The value is faster, more accurate triage with lower operational loss
A unified context layer helps the operator reduce loss exposure, improve analyst efficiency, and avoid both false negatives and costly false positives.
Operational Value
Loss preventionMore risk stopped before exposure deepens
False-positive controlBetter than blunt rules because context is richer
Analyst efficiencyCases arrive pre-contextualized
Compliance defensibilityDecision path grounded in unified evidence
Customer experienceLow-risk users pass faster, high-risk users step up sooner
Per-Event Outcome
fragmented
siloed checks
slower and noisier
→
triaged
context-first action
faster and safer
Stage 8: Outcome
Same operator stack. Different decision quality.
Without Redis, the platform relies on fragmented checks and delayed context. With Redis, the risk team and runtime path see the same operational picture in the live moment.
Fragmented Triage
DP
Deposit event for Diego
Current state
Siloed checks
Different tools, delayed joins
slow
triage
higher
noise
risk
exposure
Redis-Powered Triage
DP
Deposit event for Diego
Winning action
Step up + hold
Unified context assembled in Redis
Why this wins
Device + payment + verification signals converge
The action path is grounded in live risk context, not a single isolated score.
92%
confidence
faster
triage
lower
exposure
Stage 9: Architecture Recap
Redis becomes mission-critical decision infrastructure, not just cache
Identity, wallet, payments, case, and risk vendor systems stay in place. Redis becomes the operational context layer that makes those systems usable in the live triage path.
Data Sources

Account + KYC

Identity, documents, verification steps

Wallet + Payments

Deposits, withdrawals, rails, velocity

Sportsbook + Casino

Bet behavior, session pattern, product exposure

Device + Risk Vendors

Fingerprint, IP, geolocation, anomaly signals

Kafka / Case Feed

Transaction stream, alerts, prior reviews

Ingest Layer

RDI

Syncs account, wallet, case, and verification state

Redis Feature Form

Serves fraud, AML, velocity, and risk features online

Unified Context Layer

Redis RAM

Hot transaction path, active alert state, case step-up context

Redis Flex

Warm case history, device graph, transaction history, and risk embeddings

Feature Store

Velocity, anomaly, network risk, verification confidence

Redis Context Retriever

Assembles the Account 360 — identity state, transaction history, and risk signals — and exposes it as structured MCP tools for the decision engine

Decision Engine

Triage Rules

Thresholds, jurisdiction, product, payment policies

Risk Ranker

Fraud, AML, and confidence weighting

Network Graph Logic

Links account, device, wallet, and behavior clusters

Action Arbitration

Approve, step up, restrict, or review

Output Actions

Approve

Low-risk session continues

Step Up

Request more verification or payment challenge

Restrict

Pause deposit, withdrawal, or bonus path

Manual Review

Open case with full context attached

Decision Target
<20 ms
Primary Goal
Protect trust + limit loss
Redis Role
Operational risk context
Stage 2: Risk Event
A deposit attempt triggers a real-time triage decision
Diego attempts a high-value deposit after creating his account 40 minutes ago. He has passed light onboarding but not enhanced verification. The same device fingerprint is linked to two prior restricted accounts, and the payment instrument has unusual velocity across multiple accounts. The platform must decide immediately whether to approve, step up, or block.
High-Risk Deposit Attempt
DP
Diego Paredes
New account | 40 minutes old | Light KYC complete | High-value first deposit attempt
ELEVATED RISK
Eventdeposit_attempt
Deposit amountMXN 15,000
Account age40 minutes
Verification stateBasic onboarding complete only
Device fingerprintLinked to 2 prior restricted accounts
Payment velocityUnusual multi-account reuse pattern
Prior case historyNetwork adjacency to reviewed cluster
Why This Moment Matters
If the platform waits to understand this event later, it loses the advantage of acting in the live moment. The triage decision has to happen before the money path and risk exposure deepen.
This is where Redis becomes much more than cache. The value is not page speed. The value is a unified operational risk picture fast enough to drive the action now.
Stage 3: Ingest
Identity, wallet, device, and case systems flow into Redis
RDI synchronizes account, wallet, payment, case, and review state. Redis Feature Form serves the online features used by the triage stack. Redis becomes the live working set for risk and verification decisions.
Source Systems → Redis
KYC
Account + KYC Provider
Identity results, document checks, step-up state
→
WLT
Wallet + Payments
Deposit attempts, withdrawal state, rail history, instrument reuse
→
RISK
Device + Risk Vendors
Fingerprint, IP, geo, VPN / emulator / anomaly signals
→
CASE
Case Management
Prior reviews, outcomes, analyst notes, linked entities
→
KFK
Kafka / Redis Streams
Deposit, withdrawal, login, and gameplay event stream
→
Pipeline Status
Account + KYC syncContinuous
Payment event feedStreaming
Case history syncSub-second
Redis Feature Form parity100%
Graph query pathServed from Redis
Decision modeInline triage
Stage 4: Context
Redis assembles the live risk picture
The triage decision needs account state, payment state, device state, network adjacency, and case history in the same path. That is operational context, not simple scoring.
Redis RAMRedis FlexRedis Context Retriever
Durable Risk Context
Account historyVery new account with limited play history
Verification depthBasic onboarding only
Prior account links2 restricted accounts share device graph edge
Payment instrument behaviorSeen across multiple accounts in short window
Case historyPrior manual review cluster nearby
Jurisdiction controlsEnhanced checks required above threshold
Live Event Context
Deposit sizeHigh for a first-session deposit
Time from signup to deposit40 minutes
Geo / device confidenceModerate confidence only
Gameplay depth before depositMinimal
Bonus path exposureNot yet surfaced
Current action neededStep up or restrict, not auto-approve
Context signal: Redis Context Retriever assembles the Account 360 — identity state, transaction history, and risk signals — so the decision engine has exactly what it needs. This is not a low-risk account with a single suspicious feature. Multiple live and historical signals converge on the same triage outcome.
Stage 5: Feature Serving
Risk features hydrate in milliseconds
Redis Feature Form serves the online features that support fraud and AML triage: deposit velocity, account maturity, verification confidence, device-network adjacency, and case recurrence likelihood.
account_maturity_score
How established and behaviorally trustworthy the account appears
0.090.2 ms
deposit_velocity_score
Abnormality of transaction pattern relative to expected lifecycle
0.920.3 ms
device_graph_risk
Risk inferred from connections to known bad or reviewed entities
0.870.5 ms
verification_confidence
Confidence that current KYC level is sufficient for this action
0.280.3 ms
multi_account_payment_reuse
Strength of instrument reuse across connected accounts
0.900.4 ms
case_recurrence_likelihood
Likelihood this event should follow prior review paths
0.790.4 ms
Feature Serving Performance
Features Hydrated
151
P99 Lookup
2.4 ms
Train / Serve Parity
100%
Stage 6: Decision
Approve, step up, restrict, or review — one action wins
The triage engine evaluates the available actions using unified context. This is not a generic fraud score. It is an action decision grounded in live operational context.
#1 Winning Action
STEP UP + HOLD
Enhanced verification before deposit approval
Best action for trust protection and false-positive control
Enough converging risk to stop auto-approval, but better to step up than hard-block immediately.
Action confidence0.92
#2 Escalate
MANUAL REVIEW
Open case with full context attached
Valid fallback if enhanced verification fails or additional signals worsen
Important secondary action, but too costly as the default first move on every event like this.
Action confidence0.76
Suppressed
AUTO-APPROVE
Proceed normally
Suppressed because converging risk makes this unsafe
This is exactly the kind of action a fragmented stack is more likely to get wrong.
Action confidence0.12
Stage 7: Business Impact
The value is faster, more accurate triage with lower operational loss
A unified context layer helps the operator reduce loss exposure, improve analyst efficiency, and avoid both false negatives and costly false positives.
Operational Value
Loss preventionMore risk stopped before exposure deepens
False-positive controlBetter than blunt rules because context is richer
Analyst efficiencyCases arrive pre-contextualized
Compliance defensibilityDecision path grounded in unified evidence
Customer experienceLow-risk users pass faster, high-risk users step up sooner
Per-Event Outcome
fragmented
siloed checks
slower and noisier
→
triaged
context-first action
faster and safer
Stage 8: Outcome
Same operator stack. Different decision quality.
Without Redis, the platform relies on fragmented checks and delayed context. With Redis, the risk team and runtime path see the same operational picture in the live moment.
Fragmented Triage
DP
Deposit event for Diego
Current state
Siloed checks
Different tools, delayed joins
slow
triage
higher
noise
risk
exposure
Redis-Powered Triage
DP
Deposit event for Diego
Winning action
Step up + hold
Unified context assembled in Redis
Why this wins
Device + payment + verification signals converge
The action path is grounded in live risk context, not a single isolated score.
92%
confidence
faster
triage
lower
exposure
Stage 9: Architecture Recap
Redis becomes mission-critical decision infrastructure, not just cache
Identity, wallet, payments, case, and risk vendor systems stay in place. Redis becomes the operational context layer that makes those systems usable in the live triage path.
Data Sources

Account + KYC

Identity, documents, verification steps

Wallet + Payments

Deposits, withdrawals, rails, velocity

Sportsbook + Casino

Bet behavior, session pattern, product exposure

Device + Risk Vendors

Fingerprint, IP, geolocation, anomaly signals

Kafka / Case Feed

Transaction stream, alerts, prior reviews

Ingest Layer

RDI

Syncs account, wallet, case, and verification state

Redis Feature Form

Serves fraud, AML, velocity, and risk features online

Unified Context Layer

Redis RAM

Hot transaction path, active alert state, case step-up context

Redis Flex

Warm case history, device graph, transaction history, and risk embeddings

Feature Store

Velocity, anomaly, network risk, verification confidence

Redis Context Retriever

Assembles the Account 360 — identity state, transaction history, and risk signals — and exposes it as structured MCP tools for the decision engine

Decision Engine

Triage Rules

Thresholds, jurisdiction, product, payment policies

Risk Ranker

Fraud, AML, and confidence weighting

Network Graph Logic

Links account, device, wallet, and behavior clusters

Action Arbitration

Approve, step up, restrict, or review

Output Actions

Approve

Low-risk session continues

Step Up

Request more verification or payment challenge

Restrict

Pause deposit, withdrawal, or bonus path

Manual Review

Open case with full context attached

Decision Target
<20 ms
Primary Goal
Protect trust + limit loss
Redis Role
Operational risk context
Press ← → or click to navigate