Designing a Cross-Border Payment System: Architecture Deep Dive
Cross-border payments remain one of fintech's most complex engineering challenges. When GlobalPay Solutions engaged us to build their multi-currency payment gateway, we faced a system that needed to handle real-time FX rates across 30+ currencies, full AML/KYC compliance, and integration with banking networks spanning multiple continents — all while reducing transaction costs by at least 40%.
We achieved a 60% cost reduction. Here is how we designed the system.
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, allowing GlobalPay to 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
Results
After 12 months in production:
- 60% transaction cost reduction compared to traditional banking rails
- Sub-3-second average transaction processing time
- 99.97% uptime across all services
- Processing $50M+ in monthly transaction volume
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.