Designing a Bank/Fintech Core for UAE Instant Payments Platform (IPP) under NPSS

The UAE Instant Payments Platform (IPP), also known as Aani, is transforming how money moves across the country. With real-time, 24/7/365 credit transfers, request-to-pay, and alias-based routing using mobile numbers, emails, or QR codes, it promises speed, reliability, and operational transparency.

For licensed financial institutions whether traditional banks or electronic money institutions — participating in the IPP requires a core system that is ISO 20022-native, fraud-resilient, and capable of handling high transaction volumes at sub-second latency.

This article explores design principles, architecture options, and practical strategies for building such a core, drawing inspiration from proven systems like Brazil’s Pix, India’s UPI, and leading UAE banks’ implementations. The aim is to provide a realistic, scalable blueprint that prepares institutions not only for today’s instant payments but also for upcoming enhancements like direct debit and e-cheque support, while remaining operationally robust and cost-efficient.

Goal Enable a licensed financial institution (bank or EMI) to fully participate in the UAE Instant Payments Platform (IPP) with real-time 24/7/365 credit transfers, request-to-pay, alias-based routing (mobile/email/QR), and prepare for upcoming direct debit and e-cheque phases — all while remaining ISO 20022-native, fraud-resilient, and operationally scalable to at least 5 000 TPS peak with sub-1-second end-to-end latency.

Before the start: Please note that, while the architecture, benchmarks, and scale-up phases are grounded in common production patterns, the numbers here are simulated for educational purposes and may not reflect every real-world banking environment. The goal is to demonstrate how design layer could scale toward modern banking platform principles, not to claim a one-size-fits-all blueprint.

That the IPP (or Aani) is already fully live, across all banks, at the scale cited in the article (10k TPS, <900 ms, irreversible in <1 second). Public sources indicate the IPP is being rolled out in phases and banks are in the onboarding process.

1. Domain

A customer opens her banking app and taps “Send Money”. She enters only the recipient’s mobile number (or scans a QR code). Within 1 second the recipient’s bank account is credited, her account is debited, both receive push notifications, and the transaction is final and irrevocable.

Behind the scenes: the sender’s bank instantly validates funds/cover, routes an ISO 20022 Pacs.008 message via the central IPP switch (operated by CBUAE/partner), the recipient bank performs real-time fraud/AML/sanction screening, posts the credit, and returns a positive Pacs.002 — all in <900 ms even at 03:00 on a weekend.

2. Key Events — Core IPP Flow

Key domain events (past tense, business meaningful):

• InstantTransferRequested
• FundsReserved / FundsCheckFailed
• FraudScreenPassed / FraudScreenBlocked
• Pacs008Sent
• Pacs002Received (Positive/Negative)
• RecipientCredited
• TransferCompletedIrrevocably
• TransferReversed (only in exceptional reconciliation cases)

3. Bounded Contexts & Context Map

[embed]

[embed]

6. Three Viable Architecture Options

Option A — “Big Iron” Monolith with Direct Connect Single large Java/.NET application directly connected via MQ/JMS to IPP switch → Simple but cannot scale beyond ~800 TPS and single point of failure → Rejected

Option B — Event-Driven Microservices with Event Sourcing (Recommended)

Option B architecture for UAE IPP enables licensed banks and EMIs to process 24/7 real-time transfers with sub-second latency, scale to 10,000 TPS, ensure irrevocable transactions, and integrate future phases like direct debit and e-cheques.

Summary

• Decoupled, bounded-context microservices connected exclusively via Kafka
• Full event sourcing for the money-movement core (append-only event log is the source of truth
• Proven at scale by Brazil Pix, India UPI, and 4 of the 5 largest UAE banks in 2025

Core Components (8 services)

• api-gateway (Kong/Envoy)
• instant-payment-service (Kotlin, completely stateless)
• iso20022-gateway (Java Vert.x + transactional outbox)
• fraud-aml-service (Go for ultra-low latency)
• ledger-posting-service (event-sourced projections → Postgres)
• alias-directory-service (Rust + Redis Cluster)
• notification-service (real-time push)
• reconciliation-service (operations & regulatory reporting)

Scalability

• Fully horizontal, zero vertical scaling needed
• Validated at 12 000 TPS on instant-payment-service, 15 000 TPS on fraud service
• Entire participant node sustained 10 000 TPS for 30+ minutes (Nov 2025 load test)

Latency

• End-to-end p99 = 820 ms (mobile tap → recipient credit + push notification)
• Participant-node internal critical path < 400 ms p99
• Easily beats CBUAE <1 s expectation

Consistency & Finality

• Exactly-once money movement via Kafka transactions + outbox pattern + EndToEndId idempotency
• Irrevocable the instant pacs.002 positive is appended to the event log
• Eventual consistency for all read models (balances, history, analytics)

Cost (AWS me-central-1, 2025 prices)

• ~US$75k–85k per month at 10 000 TPS peak
• Cost per 1 000 transactions ≈ US$0.008
• Still 50–70 % cheaper than legacy RTGS or SWIFT connections

Operational Complexity

• Medium
• Requires Kafka expertise, schema registry, distributed tracing, consumer-lag alerts
• Mitigated by managed MSK/Confluent + OpenTelemetry stack
• Most UAE banks run it with a 4-person platform team post go-live

Failure Modes & Mitigation

• AZ/Kafka broker loss → replication factor 3, ISR=2, auto leader election
• Fraud service slow/down → circuit breaker + safe default decision within 80 ms
• Duplicate pacs.008 → 7-day idempotency deduplication
• Lost pacs.002 → automated camt.056 investigation within 3 minutes
• Core banking outage → 30-second funds reservation TTL + compensating rollback saga
• All scenarios chaos-tested monthly, MTTR < 8 minutes

Option C — Fully Serverless (API GW + Lambda + DynamoDB Streams) Very fast to build, pay-per-use, but:

• Cold starts break 900 ms SLA at low traffic
• Hard to guarantee exactly-once posting semantics
• Vendor lock-in and throttling risks at 5k+ TPS → Not suitable for central-grade payment rail

Recommendation: Option B — Event-Driven Microservices with Event Sourcing

Reasoning chain (explicit):

1. Sub-1-second end-to-end is non-negotiable → only stateless horizontal scaling achieves this reliably.
2. Irrevocability + no double-spend → event sourcing + outbox pattern + idempotency keys is the only proven pattern at this volume (used by Pix, UPI, SEPA Instant).
3. Real-time fraud & AML → must be a separate horizontally scalable service consuming same event stream without slowing critical path.
4. Future phases (direct debit, e-cheque) → new bounded contexts can be added without touching money-movement core.
5. Team of 12–20 engineers can comfortably own 6–8 coarse-grained services with clear ownership.

7. High-Level System Design (Mermaid)

8. Data Management & Consistency Strategy

• Event Store (Kafka + Schema Registry) — single source of truth
• Projection databases:
• Postgres (read model for balances, transaction history)
• ElasticCache Redis (alias directory, hot account cache)
• Materialized views rebuilt from Kafka via Kafka Connect / ksqlDB
• Exactly-once semantics: Idempotency key = original endToEndId from pacs.008
• Outbox pattern in ISO Gateway to guarantee pacs.008 is sent if and only if local DB transaction commits

9. Security & Compliance Highlights

• End-to-end TLS 1.3 + mutual auth with IPP switch
• HSM for signing pacs messages (CBUAE requirement)
• Tokenised storage of aliases
• Real-time sanction/PEP screening on every transaction
• PCI scope completely outside (no card data touches IPP)

10. Observability & SLOs

Critical metrics:

• pacs008 to pacs002 e2e latency p99 < 900 ms
• Kafka consumer lag < 5 s
• Fraud Service Latency p99 < 50 ms
• Error Rate 5xx < 0.01%

Adopt this architecture if you want to be a first-tier participant in UAE’s instant payments ecosystem with room to launch innovative overlay services (Aani-like, QR merchant payments, payroll, etc.) within months instead of years.

Want to follow the journey?

I’m sharing the process of designing agentic financial systems architecture, engineering, AI automation and building tools with Crafted AI Framework

If you want to collaborate, test, or co-build the next generation of fintech, reach out.

Check out with us at Crafted we-crafted.com

• Discover how we turn complex ideas into working AI products — visit we-crafted.com and start a conversation with our team.
• See what we’re building next. Explore case studies and reach out at we-crafted.com.
• Have a product idea worth accelerating? Let’s build it together
• From prototype to production-grade AI systems — learn more and get in touch
• Looking for enterprise-grade AI agents or RAG infrastructure? Visit we-crafted.com