Designing a Cross-Border Payment System: Architecture Deep Dive

Cross-border payments remain one of fintech's most complex engineering challenges: real-time FX across dozens of currencies, AML and KYC screening that satisfies every regulator in the corridor, and integration with banking networks spanning multiple continents — none of which were designed to talk to each other.

A note on provenance. This post describes architecture that engineers now at WILLNEEDS worked on at ChinaPayment, during prior employment. It was not built under the WILLNEEDS name and it is not a client engagement of ours, so we quote no outcome figures for it. We publish it because the design problems are the interesting part, and because it is the experience we would bring to a payments build.

Here is how the system was designed.

System Architecture Overview

The platform is built on an event-driven microservices architecture with four core domains:

1. FX Rate Aggregation Engine

Rather than relying on a single liquidity provider, we aggregate rates from multiple sources in real-time. The engine maintains a live order book, selects the best available rate for each currency pair, and applies a configurable markup.

Key design decisions:

• WebSocket connections to liquidity providers for sub-second rate updates
• Rate caching with configurable staleness thresholds (typically 5-15 seconds depending on currency pair volatility)
• Fallback chain — if the primary provider is unavailable, the system seamlessly falls back to secondary and tertiary providers

2. Compliance Layer

AML (Anti-Money Laundering) and KYC (Know Your Customer) compliance is non-negotiable in cross-border payments. Our compliance layer operates as a pipeline:

• Identity verification at onboarding using document verification APIs
• Transaction screening against sanctions lists (OFAC, EU, UN) for every payment
• Risk scoring using configurable rules — amount thresholds, country risk ratings, transaction velocity, and pattern detection
• Suspicious Activity Reports (SAR) generated automatically when risk thresholds are exceeded

The compliance rules engine is configurable per jurisdiction, so the platform can operate across regulatory environments without code changes.

3. Smart Routing

Not all payment corridors are equal. A USD-to-EUR transfer has different optimal routes than a USD-to-PHP transfer. Our smart routing engine evaluates:

• Cost — banking fees, FX spread, intermediary charges
• Speed — settlement time for each available route
• Reliability — historical success rates per corridor
• Compliance — regulatory restrictions on certain corridors

The router selects the optimal path based on configurable weightings, with automatic failover if a route fails mid-transaction.

4. Reconciliation Engine

Multi-currency settlement creates reconciliation complexity. Our engine handles:

• Automatic matching of inbound and outbound legs of each transaction
• Multi-currency position tracking across nostro accounts
• End-of-day settlement reports with discrepancy flagging
• Automated retry for failed settlements with exponential backoff

Technical Stack

• Backend: Java (Spring Boot) for core payment processing, Python for analytics and reporting
• Message Queue: Apache Kafka for event-driven communication between services
• Database: PostgreSQL for transactional data, Redis for rate caching and session management
• Infrastructure: AWS with multi-region deployment for latency optimisation
• Monitoring: Real-time transaction monitoring with alerting on anomalies

What the Architecture Buys You

The design goals worth calling out, rather than metrics we are not in a position to verify or claim:

• Cost — smart routing across liquidity providers and banking rails, rather than a single correspondent chain, is where the savings against traditional rails come from.
• Latency — caching aggregated FX rates and settling asynchronously keeps the user-facing path short, even when the underlying rails are slow.
• Resilience — an event-driven design means a downstream banking partner going dark degrades one corridor rather than the platform.
• Auditability — every state transition emitted as an event is what makes a regulator's reconstruction request answerable months later.

Key Takeaways

Building a cross-border payment system is as much a regulatory challenge as a technical one. The systems that succeed are those designed for configurability — because regulations, banking relationships, and market conditions change constantly.

If you are building in the payments space, contact us to discuss your architecture needs.