A fraudulent card payment flagged in 90 seconds instead of 90 milliseconds is not a technical footnote. It is money that has already left the account, a customer whose trust just took a hit, and a suspicious-activity report that starts late. Financial institutions hit this tradeoff whenever transaction processing and analytics run on separate systems. The fraud model scores against the last batch load, not the payment that just committed.
Real-time analytics in finance closes that gap. It lets a bank score a transaction against live account behavior before it settles, calculate trading risk from current positions instead of an end-of-day snapshot, and personalize an offer based on what a customer did five minutes ago. This article explains what real time means in practice, why the standard OLTP-plus-warehouse stack cannot deliver it, and how TiDB’s HTAP architecture runs analytics on live transaction data, with SQL you can try.
What Does Real-Time Analytics Mean in Finance?
Real-time analytics in finance means analytical queries run against data the moment a transaction commits, not against a copy loaded by a batch job. Near-real-time systems refresh every few minutes. That is fast enough for a dashboard and too slow to stop a fraudulent payment before it clears.
Three financial workloads depend on the difference.
- Fraud and account-takeover detection. A payment authorization has milliseconds to decide. The score has to include the last few minutes of account activity, because that is where takeover patterns show up.
- Trading and risk exposure. A trading desk needs exposure calculated from current positions. A stale position is a bad hedge.
- In-session personalization. Retail banking teams tailor offers to what a customer is doing now, not to last month’s statement summary.
Why Traditional Database Architectures Cannot Deliver Real-Time Analytics in Finance
The standard finance data stack runs transactions on an OLTP database and analytics on a separate warehouse, connected by an ETL or change data capture (CDC) pipeline. Every hop in that pipeline adds delay, and every copy is a place the numbers can drift.
Running analytics directly on the transactional database does not fix it. Large scans and aggregations compete with payment writes for the same CPU, memory, and I/O, so a month-end report can slow authorization latency at exactly the wrong moment. Most teams respond by adding read replicas, then a warehouse, then the pipeline, and end up back at a lag measured in minutes or hours.
The sync layer creates its own problems. Security and access controls have to hold in two or three systems instead of one. Reconciliation jobs catch drift only after it has reached a report. Scaling the stack for a peak such as quarter-end means scaling every component at once. This cost is why many institutions settle for near-real-time and accept the fraud and reporting risk that comes with it.
How TiDB’s HTAP Architecture Delivers Real-Time Analytics on Live Transactions
TiDB removes the separation between the transactional and analytical systems. It stores every table in TiKV, a row-based store built for transactional (OLTP) workloads, and can keep a columnar copy of the same table in TiFlash, a store built for analytical (OLAP) scans. This is hybrid transactional/analytical processing (HTAP), and it lets a fraud-scoring query read live transaction data without a pipeline and without slowing the transactions it reads.
How TiKV and TiFlash stay consistent
TiKV replicates data with the Raft consensus protocol. TiFlash replicas join each Raft group as learners and receive the same log TiKV does. That replication is asynchronous, so it adds no latency to transaction commits. When an analytical query reads from TiFlash, TiDB confirms with the Raft leader that the TiFlash replica has caught up to the query’s snapshot. The query sees every transaction committed before it started, with the same snapshot isolation TiKV provides. The result is analytics on committed data with no batch window and no reconciliation job.
TiFlash runs on its own nodes, so analytical scans use TiFlash CPU and disk, not the TiKV resources serving payments. TiDB’s cost-based optimizer chooses TiKV or TiFlash for each query, and for each table within a query. You can force a choice with a hint. See the TiDB architecture overview for how TiDB servers, TiKV, TiFlash, and PD fit together.
What real-time fraud analytics looks like in SQL
The example below adds a columnar replica to a payments table, confirms it is ready, and runs a fraud-style aggregation that compares each account’s last hour against its 30-day baseline.
-- Add a columnar replica of the transactions table
ALTER TABLE transactions SET TIFLASH REPLICA 1;
-- Check replication progress (AVAILABLE = 1 when ready)
SELECT TABLE_NAME, REPLICA_COUNT, AVAILABLE, PROGRESS
FROM information_schema.tiflash_replica
WHERE TABLE_SCHEMA = 'payments' AND TABLE_NAME = 'transactions';
-- Flag accounts whose last-hour spend exceeds 3x their average daily spend
SELECT /*+ READ_FROM_STORAGE(TIFLASH[t]) */
t.account_id,
SUM(CASE WHEN t.created_at >= NOW() - INTERVAL 1 HOUR THEN t.amount ELSE 0 END) AS last_hour_total,
SUM(t.amount) / 30 AS avg_daily_total_30d
FROM transactions t
WHERE t.created_at >= NOW() - INTERVAL 30 DAY
GROUP BY t.account_id
HAVING last_hour_total > 3 * avg_daily_total_30d;The first statement is the only schema change HTAP requires. Application writes keep going to TiKV unchanged. The final query scans 30 days of transactions for every account, the kind of aggregation that competes with payment writes on a row store. On TiFlash it reads only the three columns it needs from columnar storage, while the payment path keeps its TiKV resources. The hint makes the routing explicit. Without it, the optimizer chooses the engine based on cost.
When a separate warehouse still makes sense
HTAP does not replace every analytics system. A warehouse or lakehouse remains the better fit for multi-year history that no transaction path touches, for joins across data from many source systems, and for BI workloads analysts run all day. TiDB’s strength is the operational layer, where analytics must reflect the transaction that just committed. Many teams run TiDB for that layer and keep a warehouse for long-range analysis, fed by TiCDC.
What Real-Time Fraud Detection and Compliance Look Like on TiDB
Fraud detection is where lag between transactional and analytical systems costs the most. With TiFlash reading committed transactions, a fraud model scores a payment against the account’s recent behavior before it settles, instead of flagging it in a batch run hours later.
Anti-money laundering follows the same pattern at a larger scale. AML monitoring aggregates transfers across accounts and time windows to spot structuring and layering, which is analytical work that has to run against current data. PingCAP has documented how top global banks use HTAP databases for anti-money laundering.
Compliance reporting benefits the same way. A regulatory report built from a nightly snapshot is accurate when the batch runs and stale by the time someone reads it. Running the same query against live data removes that class of error and shortens the time between period close and a submitted report.
The platform underneath has to hold up under financial workloads first. MNC Bank moved to TiDB and reported 10x higher throughput, 50% lower latency, and 85% faster backups. For more financial workloads running on TiDB, see TiDB for fintech.
The gap between a transaction committing and an analytics system seeing it is where fraud losses, reporting errors, and missed trading windows live. Closing it does not require a warehouse and a pipeline beside production. It requires one database that serves both workloads from the same committed data.
To test real-time analytics in finance on your own schema, start a free TiDB Cloud Starter cluster, add a TiFlash replica, and run a fraud-style aggregation against live writes.
Real-Time Analytics in Finance FAQ
What is real-time analytics in finance?
Real-time analytics in finance is analysis that runs against transaction data the moment it commits, rather than against a copy loaded by a nightly or hourly batch job. Banks, payment companies, and trading firms use it to score payments for fraud before they settle, calculate risk exposure from current positions, and personalize offers during a customer session. It requires a database that can serve analytical queries on live data without slowing down the transactions producing that data.
How is real-time analytics different from near-real-time analytics?
Real-time analytics reads data as of the latest committed transaction. Near-real-time analytics reads a copy refreshed on a schedule, every few minutes or longer, through an ETL or CDC pipeline. For a dashboard, a few minutes of delay is acceptable. For fraud detection it decides the outcome, because a payment authorization finishes in milliseconds and a fraudulent transaction can clear long before the next refresh. The pipeline behind near-real-time systems also adds a place where data can drift out of sync.
How does TiDB support real-time analytics without ETL?
TiDB keeps two storage engines in one cluster. TiKV stores rows for transactions, and TiFlash keeps a columnar replica of the same tables for analytics. TiFlash receives changes through the Raft consensus log as a learner, so no ETL job copies data between them. Before serving a query, TiFlash confirms it has caught up to the query’s snapshot, so results include every transaction committed before the query began. Enabling this for a table takes one statement: ALTER TABLE … SET TIFLASH REPLICA 1.
Can real-time analytics run alongside live transaction processing without slowing it down?
Yes, when analytical queries run on separate storage from transactions. In TiDB, TiFlash runs on its own nodes, so large scans and aggregations consume TiFlash CPU, memory, and disk rather than the TiKV resources serving payments. TiFlash replicates asynchronously, which means adding analytical replicas does not add latency to transaction commits. The TiDB optimizer routes each query to the engine best suited to it, and hints let you force a query onto TiFlash when you want explicit isolation.