REFERENCE ARCHITECTURE · BANKING & FINTECH
Design Fraud Analytics Around the Decision Path.
Protect digital transaction experiences by separating real-time decisions, operational data access, investigative analytics and governed history. Build auditable risk workflows with explicit ownership of scoring logic, feature freshness, query performance and incident handling.
For fraud technology leads · risk data architects · banking CTO / CDO office. Stack: Redis · ClickHouse · Trino OSS or Starburst · DataHub · dbt · PostgreSQL
THE CHALLENGE
Real-Time Risk Intelligence Without Sacrificing Governance.
Bring together transaction events, customer context and historical risk signals through an architecture that separates low-latency operational decisions from investigations and analytical reporting. Bassirah helps teams define where Redis, ClickHouse, Trino or Starburst, PostgreSQL, and metadata governance each belong—and where a dedicated scoring service or streaming pipeline remains essential.
- A tight decision window — Every additional network hop, lookup or query on the transaction path adds latency and a new failure mode.
- Analytics in the wrong place — Investigation and reporting queries placed on the synchronous path compete with authorisation traffic.
- Stale or inconsistent features — Online features drift from source systems without explicit freshness, expiry and fallback rules.
- Audit and lineage pressure — Regulators, auditors and model-risk teams need to trace a decision back to its data, model version and owner.
ARCHITECTURE OVERVIEW
Keep the Decision Path Short. Put Everything Else Beside It.
The synchronous path runs from the transaction gateway to the institution’s risk decision service and its online feature lookup. Investigation, federation and governance consume the same events asynchronously, so they never slow the decision.
Figure 1. Banking Fraud & Risk Data Platform reference architecture (conceptual). Colour key: see How to read our diagrams.
Logical Decision and Data Flow
- Submit the transactionTransaction gateway / core system submits an event to a risk decision application; approval logic and model scoring remain owned by the financial institution or designated application.
- Look up online featuresFast online feature retrieval may use Redis under strict consistency, access and expiration policies; source-of-truth data resides in authoritative operational systems.
- Investigate asynchronouslyEvents and historical activity feed ClickHouse for fraud investigations, monitoring and trend analysis rather than assuming OLAP is in the synchronous transaction decision path.
- Query governed sourcesTrino OSS or Starburst may connect governed risk/history sources for exploratory and regulatory queries; unnecessary federation is avoided for latency-critical scoring.
- Build analytical trustDataHub lineage and dbt-validated data models improve analytical trust where integrated; permissions are still enforced in the underlying systems and query access control points.
Conceptual pattern. Connectors, licensed capabilities, versions, security policies and topology are validated in a project-specific architecture.
Last reviewed: — · Version scope: —
COMPONENT ROLES
Who Does What in the Stack
| Component | Classification | Role | Qualification |
|---|---|---|---|
| Transaction gateway / core banking | Customer-owned | Submits transaction events and applies the final decision | Owned and operated by the institution |
| Risk decision service (rules + model scoring) | Customer-owned or designated application | Approve, decline or step-up decisions | Scoring logic, models and thresholds owned by the institution |
| Redis | Strategic partner | Online feature lookup on the decision path | Strict consistency, access and expiry policies; not the system of record |
| Event streaming / CDC | Customer-owned or separately selected | Deliver events and changes to analytics and features | Ordering, replay and delivery semantics agreed per stream |
| ClickHouse | Partner-led or ClickHouse OSS route | Fraud investigation, monitoring and trend analytics | Asynchronous to the decision path by design |
| Trino OSS or Starburst | Independent OSS support or strategic partner (choose one) | Exploratory and regulatory queries across governed sources | Not used for latency-critical scoring |
| DataHub Core + dbt Core / dbt OSS | Independent OSS support | Lineage, ownership and tested analytical models | DataHub documents and traces; it does not enforce authorisation |
Links: Redis · ClickHouse partner · ClickHouse OSS · Trino OSS · Starburst · DataHub · dbt · PostgreSQL
DESIGN TRADEOFFS
Decisions That Protect the Latency Budget
| Decision | Options | Choose based on | Validate with |
|---|---|---|---|
| Feature serving | Redis online features · Features computed inside the scoring service · Direct reads from operational database | Latency budget per stage, feature freshness, consistency needs | p95/p99 lookup latency under peak load; staleness measurement |
| Feature freshness | Streaming updates · Micro-batch refresh · On-demand fetch with TTL | How quickly a risk signal must affect decisions | End-to-end freshness test from source event to feature |
| Fallback behaviour | Fail-open with limits · Fail-closed · Step-up authentication | Risk appetite, customer impact, regulatory expectations | Chaos test: feature store, model or network unavailable |
| Investigation store | ClickHouse · Existing warehouse · Federated queries only | Query volume, investigator concurrency, retention | Investigator query latency and alert turnaround in PoC |
| Federated access | Trino OSS or Starburst · No federation | Number of sources, governance model, commercial support needs | Connector semantics, access-control behaviour, throughput |
| Redis durability | Cache-only with rebuild · Persistence and replication · Multi-site topology | Recovery time for features after failure | Restore and rebuild drill; consistency checks against source |
- OLAP and federated SQL are not placed in the synchronous authorisation path by default.
- Redis is not the authoritative store for customer, account or transaction data.
- Observability, lineage and catalogs do not replace access control. Permissions are enforced in the underlying systems and query engines.
Not sure where your latency is going?
Start with transaction-path profiling.
SECURITY & RESILIENCE
Auditable by Design, Recoverable by Test
Least-privilege access
Separate service identities for scoring, feature updates, investigation and reporting. Enforce access in Redis, ClickHouse, the SQL engine and source systems, not in the catalog.
Sensitive data handling
Tokenise or mask card and account identifiers where possible, and keep sensitive fields out of analytical copies that do not need them. Designed to support your compliance obligations.
Encryption & keys
Encrypt traffic on every hop, including the decision path, and data at rest where supported, with keys in your HSM or KMS.
Decision audit trail
Record the event, features used, model version, rule outcome and decision for each transaction, retained according to policy and queryable by investigators.
RPO / RTO per subsystem
Define recovery separately for the decision service, feature store, event streams and analytical stores. The decision path usually needs the strictest objectives.
Incident readiness
Runbooks for feature-store loss, model rollback, stream lag and analytical outages, with alerting on latency budget breaches.
PROOF & OUTCOMES
Define Success Before You Measure It
Agree an end-to-end risk API SLO, p95/p99 latency budget per stage, model precision/recall, decision correctness, alert investigation turnaround, data drift thresholds and evidence retention. A “<5 ms" response is a candidate benchmark target only when the customer environment and chosen scoring path prove it.
Measurement Plan
| Metric | How it is measured | Target |
|---|---|---|
| Decision time | Validated p95 / p99 end-to-end decision time, broken down by stage (gateway, feature lookup, scoring, response) | Latency targets validated on the customer's scoring and data-access path |
| Detection quality | Model precision / recall and decision correctness on a labelled evaluation set | Agreed with fraud and model-risk owners |
| Operational availability | Availability of the decision path, including fallback behaviour under component failure | Agreed SLO |
| Investigation turnaround | Time from alert to investigator answer using the analytical store | Agreed with fraud operations |
| Lineage coverage | Share of reporting and model-input datasets with documented owner and lineage | Agreed with data governance |
| Data drift | Monitored drift of key features against agreed thresholds | Agreed per model |
What You Receive
- Architecture decision record
- Target SLOs and a per-stage latency budget
- Secure data-flow model
- Phased PoC acceptance criteria
- Transaction-path profiling results
Banking Fraud & Risk Data Platform FAQs
Does Bassirah provide the fraud scoring model?
No. Approval logic and model scoring remain owned by the financial institution or its designated application. Bassirah designs and operates the data platform around it: feature access, event delivery, investigation analytics, federation, lineage and resilience.
Can fraud scoring run in under 5 milliseconds?
That can only be stated after measurement. A “<5 ms" response is a candidate benchmark target when your environment and chosen scoring path prove it. We agree a per-stage latency budget and measure p95/p99 end-to-end decision time in a proof of concept.
Why is ClickHouse not in the transaction decision path?
ClickHouse is a column-oriented database designed for high-performance analytical queries, which suits investigations, monitoring and trend analysis. Keeping it asynchronous protects the decision path from investigative query load and lets each system be scaled and recovered for its own purpose.
Is Redis the source of truth for customer or account data?
No. Redis serves online features under strict consistency, access and expiry policies. Authoritative customer, account and transaction data stays in the institution’s operational systems, and features can be rebuilt from them.
Does DataHub enforce who can see risk data?
No. DataHub provides metadata, ownership and lineage visibility. Access permissions are enforced in the underlying databases, object storage and query engines, such as the Trino OSS or Starburst access-control configuration.
Related Pages
Data Quality & MDM for DataHub
Bassirah’s governed DataHub catalogue with quality gates and master data management.
GenBI (Chat With Your Data)
Bassirah’s conversational analytics in Arabic and English, with a trust label on every answer.
Plan a Fraud Analytics PoC.
Bring your decision path, data sources and latency objectives. We will agree SLOs, a per-stage latency budget and phased acceptance criteria.