Gailad Chesa Engineering Leadership OS Let's Talk

Fintech Payments

Scaling a High-Volume Payments Platform

Fintech Payments Platform / Instant and EFT payment rails

  • Industry context. Fintech — consumer payments
  • Timeframe. Focused multi-month performance programme
  • Scale of involvement. Led technical direction within the Payments team, with senior engineering collaboration across the platform

13K → 32K

Transactions per day across instant and EFT rails

Roughly 2.5× sustained capacity, with resilience and settlement integrity preserved

At a glance

Industry
Fintech — consumer payments, where customers expect money to arrive in seconds.
My role
Engineering leadership in the Payments team: technical strategy, architecture, prioritisation and delivery.
Partnerships
Instant mobile payment rails — eWallet, CashSend, Instant Money and Send-iMali — alongside EFT providers Ozow, Stitch, WalletDoc and OwnPay.
Team scale
Technical direction led within the Payments team, with senior engineering collaboration across the platform.
Technical landscape
Distributed transaction processing, event-driven architecture, asynchronous pipelines, reconciliation and observability.
Complexity
Every rail carries its own contract, failure modes and settlement behaviour. A failed payment is not simply a retry — it is a customer who cannot reach their own money.
Outcome
Sustained capacity rose from roughly 13,000 to 32,000 transactions per day, with stronger resilience and operational reliability across every rail.

The challenge

A consumer payments platform was approaching throughput limits across instant mobile and EFT payment rails, and needed significant improvements in scalability, resilience and processing performance — without ever putting customer money in doubt.

Context

A high-volume consumer payments environment in fintech, where money moves across several very different rails — bank instant-money products and third-party EFT providers — each with its own contract, latency profile and behaviour under load.

The real problem

The platform was approaching processing limits. The risk was not only slower throughput, but reduced operational headroom on a service where every delay is felt directly by a customer waiting for their own funds.

My role

Led the engineering effort within the Payments team across technical strategy, architecture, prioritisation and delivery. Partnered with senior engineers to identify processing bottlenecks across each payment rail and introduce a more scalable approach to asynchronous, distributed transaction processing.

  • Architecture direction
  • Technical decision-making
  • Senior engineer collaboration
  • Delivery ownership
  • Performance prioritisation
  • Operational considerations

The integration landscape

Instant mobile payment rails

eWallet CashSend Instant Money Send-iMali

EFT payment providers

Ozow Stitch WalletDoc OwnPay

The decision

Prioritise architecture and concurrency improvements over superficial infrastructure scaling. Focus on how work moved through the system, not only how many machines were available.

Approach

Directed technical strategy and prioritisation, worked with senior engineers on bottleneck analysis rail by rail, and built the working relationships with payment partners needed to understand each provider's real limits rather than its documented ones. Sequenced delivery so performance gains could be verified without compromising correctness or settlement integrity.

Architecture lens

Sanitised view of a distributed payments shape: request ingress and validation, limit and risk checks, orchestration across multiple instant and EFT rails, asynchronous/event-oriented processing paths, durable stores, reconciliation and observability. Emphasis on reducing synchronous constraints, isolating per-provider failure so one rail cannot take the others down, and keeping settlement auditable end to end.

Distributed payments processing shape A payment request passes through ingress and validation, then limit and risk checks, then orchestration. At that point it crosses an asynchronous boundary onto an event-oriented processing path, which fans out to two isolated groups of rail workers: four instant mobile rails and four EFT providers. Each group has its own failure boundary, so one provider degrading cannot take the others down. Both groups write to a durable store, which feeds reconciliation and settlement. Observability spans every stage. Payment request Ingress & validation Limit & risk checks Orchestration asynchronous boundary Event-oriented processing INSTANT RAILS eWallet · CashSend Instant Money EFT PROVIDERS Ozow · Stitch WalletDoc · OwnPay each group fails on its own Durable store Reconciliation & settlement OBSERVABILITY
Sanitised view. The two decisions that mattered: moving work across an asynchronous boundary so throughput stopped being bounded by synchronous calls, and giving each provider its own failure boundary so one rail could not degrade the rest.

Outcome

Sustained transaction processing rose from roughly 13,000 to 32,000 transactions per day across both instant mobile and EFT rails — about 2.5× the original capacity — with stronger resilience and operational reliability.

  • Sustained throughput up from roughly 13,000 to 32,000 transactions per day across the rails
  • Per-provider failure isolation, so one rail cannot degrade the others
  • Reduced synchronous processing constraints
  • Settlement integrity and reconciliation preserved throughout

Lesson

Throughput problems are usually systems problems. In payments they are also trust problems — the constraint you remove has to leave correctness and settlement completely untouched.

Capabilities involved

Fintech Payments Banking Integrations Distributed Systems Event-Driven Architecture Kafka Performance Engineering