All cases
Fintech · Highload

Payments core & anti-fraud for a bank

Meridian is a retail bank. Its core computed balances on the fly and drifted after reference-data edits, anti-fraud ran on manual rules, and payday peaks brought the system down. We built a transaction core on an immutable operation ledger: balance is a projection of facts, payments are idempotent, anti-fraud runs on the stream, and the cluster holds peak in active-active.

1 200
TPS at peak
99.99%
availability
Transactionslive
₽ 12,400OK
₽ 980Fraud
₽ 5,600OK
Anti-fraud1,240 TPS

Challenge

The legacy core stored mutable balances and recomputed them on the fly. After reference-data edits and manual corrections the numbers drifted, and reconciliation took days.

Anti-fraud ran on static rules and triggered after the fact. On paydays and sales the load grew several-fold, while the system scaled only vertically — hit a ceiling and went down at night.

Solution

We moved to event sourcing: every operation is an immutable fact in the ledger, and the balance is computed as a projection of those facts. History can't be rewritten, reconciliation is instant and always matches. Payments are idempotent by key — a repeated request never double-charges.

Anti-fraud moved to stream processing: rules and scoring on every transaction in real time, with suspicious ones held or blocked. Double-entry accounting, an audit log of every action, role-based access and a four-eyes rule on critical operations.

The core is stateless services behind an event bus, active-active across two zones with automatic failover and horizontal scaling for peaks. SBP and NSPK integrations with idempotent retries, observability from day one.

Outcome

Zero balance discrepancies after edits, reconciliation in seconds instead of days. Anti-fraud cuts fraudulent operations on the fly. The cluster holds payday peaks with no latency degradation.

The bank got a core whose numbers can be trusted, and a platform that scales horizontally instead of hitting a server ceiling.

What's inside

Immutable ledger

Every operation is a fact that can't be rewritten. Balance is a projection; reconciliation always matches.

Idempotent payments

An idempotency key on every payment: a repeated request never double-charges.

Streaming anti-fraud

Rules and scoring on every transaction in real time: suspicious ones held or blocked.

Double-entry & audit

Double-entry accounting, an audit log of every action, four-eyes on critical operations.

Active-active

Stateless services behind an event bus, two zones, automatic failover with no downtime.

SBP & NSPK

Integrations with national payment systems: idempotent retries and reconciliation.

Under the hood

A payment is an idempotent fact in the ledger.

Every payment passes idempotency and anti-fraud checks, then is appended as an immutable event to the ledger. A retry never double-charges, and the balance is a projection of facts.

PYpayments.goFastAPI · async
$ POST /payments → 201 · ledger append · fraud ok · idempotent

Stack

Core
  • Go
  • gRPC
  • PostgreSQL
Event stream
  • Apache Kafka
  • Schema Registry
Anti-fraud
  • ClickHouse
  • Redis
  • Потоковый скоринг
Infrastructure
  • Kubernetes
  • Docker
  • ArgoCD
  • Vault
Observability
  • Prometheus
  • Grafana
  • OpenTelemetry
Integrations · Security
  • СБП
  • НСПК
  • mTLS
  • RBAC
  • Аудит
🥷 Код принят. Хочешь к нам — расшифруй и пришли разгадку на hello@itkiller.pro:
SVRLLVJFQURZLVRPLUJVSUxE