Seba started from a technical problem we kept seeing in payment fraud: fraud detection is not one model, one rule, or one dashboard. It is a real-time systems problem.
Payment companies need to answer two very different questions at the same time:
- Should this transaction be approved right now?
- Why is this customer, device, merchant, or ring becoming risky over time?
Those two questions have completely different infrastructure needs. The first needs sub-100ms decisioning, entity lookups, idempotent writes, and rolling velocity counters. The second needs analytics, joins, recursive graph traversal, rule-performance analysis, audit trails, and investigator workflows.
That is why we built Seba as a real-time fraud decisioning system for the Saudi payment market, with a dual-store architecture and an agentic investigation layer from the beginning.
What it does
Seba is a real-time fraud decision API and analyst console for payment providers, banks, wallets, BNPLs, ecommerce platforms, and acquirers operating in Saudi Arabia.
A payment system can send Seba events like:
- payment attempts
- new device activity
- refunds
- payouts
- chargebacks
- merchant activity
- manual-review feedback
Seba returns an explainable decision:
approve
step_up
hold
manual_review
block
The scoring engine detects patterns like velocity spikes, impossible travel, new-device risk, card testing, mada card testing, STC Pay wallet takeover, BNPL abuse, refund abuse, merchant payout risk, payment-link fraud, and POS terminal velocity. The demo includes 14 simulator scenarios that seed live data for these patterns.
The product is not only a score API. It includes:
- real-time scoring
- entity risk graph
- case management
- AI Investigator
- fraud-ring investigations
- merchant monitoring
- policy studio
- pilot backtesting
- AI Ops dashboard
- SAMA evidence export
- API integration guide
How we built it
We built Seba as a dual-path fraud system.
The hot path is optimized for real-time payment decisions. When a client calls:
POST /api/v1/risk/score
Seba resolves the tenant from the API key, reads entity features for the customer, device, IP, merchant, and card, builds a scoring context, evaluates 30+ deterministic fraud rules, writes the transaction idempotently, opens a case if needed, updates rolling entity features, and returns the decision to the client.
The warm path is optimized for analytics and investigations. We mirror transaction, case, rule, and note data into Aurora PostgreSQL asynchronously so dashboards and investigations can run SQL queries without touching the decision latency path.
The key architecture decision is:
DynamoDB handles the decision. Aurora explains it.
DynamoDB is used for the hot decision path because it gives us single-key entity lookups, conditional writes for idempotency, and atomic counters for velocity and feedback signals. Aurora PostgreSQL is used for analytics, joins, recursive CTEs, window functions, row-level security, fraud-ring traversal, and audit trails.
We chose this because one database cannot optimize for both sub-10ms scoring and complex analytical queries. A relational database gives rich SQL but weakens predictable single-digit-millisecond latency under write load. A key-value store gives fast lookups but cannot do joins, group-bys, window functions, or recursive graph traversal. Seba splits the workload and bridges both stores with an async mirror.
The scoring engine itself is deterministic and explainable. It evaluates rule groups around feedback, velocity, amount, geo/device, payee, merchant, links, Saudi payment flows, and behavioral signals. The architecture separates scoreTransaction() as a pure function with no I/O, making it unit-testable and easy to explain to analysts and regulators.
The agentic layer sits on top of this architecture. The AI Investigator is not just a chatbot. It gathers evidence from DynamoDB, runs link-analysis queries on Aurora, checks guardrails, produces a recommendation, assigns a confidence band, writes an investigation narrative, and suggests an analyst note.
Challenges we ran into
The first challenge was designing a fraud system that is both fast enough for payment authorization and deep enough for investigations.
If everything lived in Aurora, scoring could be slowed by connection pools, cold starts, and index-heavy writes. If everything lived in DynamoDB, we would lose joins, rule analytics, recursive fraud-ring detection, and SQL-based investigations. The dual-store design solved this, but it forced us to be very strict about what belongs in the hot path and what belongs in the analytical path.
The second challenge was keeping the scoring path isolated. The async mirror must never block the API response. If Aurora is unavailable, the transaction still needs to be scored, stored in DynamoDB, and returned to the payment company. Aurora can be backfilled later.
The third challenge was making the agentic system useful without making it dangerous. Fraud investigations need automation, but not blind automation. So the AI Investigator is designed around evidence gathering, guardrail checks, confidence bands, and audit-ready recommendations instead of directly making irreversible decisions.
The fourth challenge was productizing policy experimentation. Fraud teams need to tune thresholds, enable or disable rule groups, and compare policies without touching production. That is why we built Policy Studio with backtests, champion/challenger comparison, and shadow-mode policy runs.
Accomplishments that we’re proud of
We are proud that Seba is not just a prototype screen. It is an end-to-end technical system.
We built:
- a real-time fraud scoring API
- a deterministic rule engine with 30+ fraud rules
- entity-centric rolling features for customers, devices, IPs, merchants, and cards
- a DynamoDB hot path for payment decisioning
- an Aurora analytical path for dashboards and investigations
- async fire-and-forget mirroring between both stores
- case auto-opening for hold, review, and block decisions
- an agentic AI Investigator
- fraud-ring detection using recursive CTEs
- Policy Studio for backtesting and shadow evaluation
- merchant monitoring for refund pressure and payout exposure
- SAMA evidence export with controls, decision volume, case volume, feedback, latency, and rule summary
The fraud-ring investigation is one of the parts we are most proud of. Aurora’s recursive CTE traverses shared devices, IPs, and cards to uncover fraud rings entirely in SQL, which is something DynamoDB cannot do.
We are also proud of the AI Ops layer. It tracks agent runs, recommendation breakdowns, guardrail status, evidence count, duration, and estimated analyst time saved.
What we learned
We learned that fraud detection is not just about catching suspicious transactions. It is about building the operating system around fraud decisions.
A production fraud system needs:
- real-time scoring
- entity memory
- idempotency
- policy control
- feedback loops
- explainability
- case management
- graph investigations
- analyst workflows
- compliance evidence
- safe experimentation
We also learned that agentic AI is strongest when it is grounded in structured systems. The AI Investigator becomes useful because it can pull from entity history, transaction records, case data, rule triggers, and graph analysis. Without that architecture, the agent would just be summarizing. With the architecture, it becomes an investigation worker.
The biggest technical lesson was that fraud platforms are both OLTP systems and analytical graph systems. Trying to force both workloads into one database creates bad compromises. Splitting the system into DynamoDB for decisions and Aurora for explanations made the architecture cleaner, faster, and easier to reason about.
What’s next for Seba
Next, we want to move Seba from demo-grade simulation into real shadow-mode evaluation with Saudi fintech and payment companies.
Technically, the next steps are:
- Run shadow-mode pilots
- ingest copied or historical payment events
- score transactions without affecting live payments
- compare Seba decisions against real outcomes
- measure fraud caught, false positives, review load, and decision latency
- Expand the agentic investigation workflow
- deeper evidence collection
- stronger guardrails
- richer investigation narratives
- analyst feedback loops
- automated evidence packs per case
- Strengthen the policy engine
- better champion/challenger testing
- more isolated backtest state
- customer-specific policies
- safer promotion from draft to production
- Prepare for SAMA sandbox
- package compliance evidence
- document controls
- define pilot scope
- prove latency and auditability
- work with licensed Saudi payment partners
- Move toward production decisioning
- start with shadow mode
- then advisory recommendations
- then controlled step-up / hold / review actions
- eventually full real-time decision support, while the licensed PSP or bank remains the final decision-maker
The technical vision is simple:
Seba becomes the Saudi fraud decision infrastructure layer where DynamoDB makes the real-time decision, Aurora explains the pattern, and agentic investigators help analysts move from alert to evidence-backed action.
Built With
- v0
Log in or sign up for Devpost to join the conversation.