System Design: International Remittance System

Requirements

Functional Requirements:

• Send money internationally across 50+ corridors (country pairs) with real-time FX rate quotes
• Multiple delivery methods: bank deposit, mobile money, cash pickup at agent locations
• Transparent fee structure with guaranteed exchange rate locked at transaction time
• Recipient notification via SMS/email when funds are available for collection
• Transaction tracking from initiation through delivery with status updates
• Compliance: sanctions screening (OFAC, EU, UN), AML transaction monitoring, travel rule compliance

Non-Functional Requirements:

• Process 2M transfers/day across all corridors with sub-minute FX quote response
• Delivery SLA: bank deposits within 1 hour for major corridors, cash pickup within 15 minutes
• 99.9% availability for the transfer initiation flow
• FX rate accuracy within 0.01% of market mid-rate at quote time
• Regional data residency compliance (GDPR for EU senders, PDPA for Asian corridors)

Scale Estimation

At 2M transfers/day = 23 TPS average, peaking at 100 TPS around month-end (payday remittance spikes). Average transfer size is $300, totaling $600M/day or $219B/year in volume. Each transfer triggers: FX rate quote, sender KYC verification, sanctions screening (against 50K+ sanctioned entities), AML risk scoring, funding (debit sender's payment method), FX conversion, and payout via corridor-specific delivery rail. FX rate quotes: 50 corridors × 100 rate updates/hour = 5,000 rate updates/hour from liquidity providers. Sanctions screening must complete in under 5 seconds against lists totaling 500K entries including fuzzy name matching.

High-Level Architecture

The remittance platform is architected around the concept of payment corridors — each country-to-country pair has specific routing rules, delivery partners, regulatory requirements, and FX providers. A Corridor Router Service determines the optimal path for each transfer based on the origin country, destination country, delivery method, and amount.

The transfer flow: Sender initiates transfer → FX Pricing Service provides a guaranteed rate quote (valid for 30 seconds) → Sender confirms → Compliance Service runs sanctions screening and AML checks → Funding Service collects money from sender (ACH, debit card, bank transfer depending on origin country) → Treasury Service manages FX conversion (either via internal netting or external FX execution with liquidity providers) → Payout Service routes funds to the destination via corridor-specific partners (bank APIs, mobile money operators like M-Pesa, cash pickup networks like MoneyGram agents).

The Treasury Layer is critical for profitability. Instead of converting each transfer individually (expensive), the Treasury Service aggregates transfers in the same corridor direction over a time window (e.g., all USD→INR transfers in the last 15 minutes) and executes a single bulk FX trade with a liquidity provider. For popular corridors, Wise-style internal netting matches opposing flows (USD→GBP senders against GBP→USD senders) to eliminate FX conversion entirely.

Core Components

FX Pricing Service

The FX Pricing Service provides real-time exchange rate quotes to senders. It maintains a rate engine that consumes live mid-market rates from multiple liquidity providers (Reuters/Refinitiv, Bloomberg, and direct bank feeds) and calculates the offered rate by applying: (1) the mid-market rate, (2) the platform's FX markup (varies by corridor, typically 0.3-1.5%), (3) volume-based discounts for large transfers. Rates are refreshed every 10 seconds for major currency pairs and every 60 seconds for exotic pairs. A rate-locking mechanism guarantees the quoted rate for 30 seconds — during this window, the platform hedges its FX exposure by placing a forward order with the liquidity provider. The rate engine uses a weighted median across providers (discarding outlier quotes) to prevent manipulation.

Compliance & Sanctions Screening

Every transfer undergoes multi-layered compliance checks. First, real-time sanctions screening matches sender and recipient names against OFAC SDN, EU Consolidated List, UN Security Council, and 20+ country-specific lists (total 500K+ entries). Name matching uses a combination of exact match, phonetic matching (Soundex/Metaphone), and fuzzy matching (Levenshtein distance with threshold 0.85) to catch evasion attempts (name variations, transliterations). Matches above the threshold go to a manual compliance review queue. Second, AML risk scoring evaluates the transaction against ML models trained on suspicious patterns: structuring (multiple transfers just below reporting thresholds), unusual corridors for the sender's profile, round-amount transfers, and velocity anomalies. Transfers scoring above the risk threshold generate SARs (Suspicious Activity Reports) filed with FinCEN. Third, travel rule compliance for transfers above $3,000 requires transmitting originator and beneficiary information to the receiving institution.

Payout Network Integration

The Payout Service integrates with 200+ delivery partners across 50+ countries. Each partner has a different API contract, settlement cycle, and reliability profile. Partner types include: bank networks (SWIFT for large-value, local RTGS/ACH for domestic legs), mobile money operators (M-Pesa, GCash, bKash), cash pickup networks (Western Union agents, postal offices), and e-wallets (Paytm, GrabPay). The Integration Layer normalizes all partner APIs into a unified internal payout interface. A Partner Health Monitor tracks each partner's availability, success rate, and settlement latency, feeding into the Corridor Router's partner selection algorithm. When a primary partner is degraded, the router automatically fails over to an alternative delivery partner, notifying the sender of any delivery method changes.

Database Design

The core database is PostgreSQL (Citus-sharded by sender_id). Key tables: transfers (transfer_id, sender_id, recipient_id, source_country, dest_country, source_currency, dest_currency, source_amount NUMERIC(18,4), dest_amount, fx_rate, fx_rate_locked_at, fee, status, corridor_id, payout_partner_id, created_at), recipients (recipient_id, sender_id, name, country, delivery_method, bank_account/mobile_number/agent_location, created_at), compliance_checks (check_id, transfer_id, check_type SANCTIONS/AML/TRAVEL_RULE, result PASS/FAIL/REVIEW, details JSONB, checked_at).

FX rate history is stored in TimescaleDB for audit and analytics: fx_rates (currency_pair, provider, bid, ask, mid, captured_at) with 1-second granularity retention for 30 days, downsampled to 1-minute for 2 years. The sanctions list database uses PostgreSQL with trigram indexes (pg_trgm extension) for efficient fuzzy name matching. Lists are refreshed daily from official sources via automated SFTP/HTTP pulls.

API Design

• POST /v1/quotes — Get an FX rate quote; body contains source_currency, dest_currency, source_amount or dest_amount, delivery_method; returns rate, fee, dest_amount, rate_expiry_at (30 seconds)
• POST /v1/transfers — Initiate a transfer using a quote; body contains quote_id, recipient_id, funding_source_id, idempotency_key; returns transfer_id, status, estimated_delivery
• GET /v1/transfers/{transfer_id} — Track transfer status with detailed timeline (funded, compliance_passed, fx_converted, payout_initiated, delivered)
• POST /v1/recipients — Save a recipient for future transfers; body contains name, country, delivery_method, account_details

Scaling & Bottlenecks

Sanctions screening is the latency-critical bottleneck. Fuzzy matching a name against 500K entries takes ~200ms with naive implementation. The screening service uses a pre-computed trigram index and a tiered matching strategy: exact hash match first (sub-ms), then phonetic match (5ms), then fuzzy match only if phonetic produces no results (50ms). The sanctions list is loaded into memory as a trie structure for prefix matching. Scaling is horizontal: each screening server holds the full list in memory (2GB) and processes requests independently.

FX netting optimization requires accumulating transfer volume before executing bulk trades. This creates a tension between speed (users want instant conversion) and efficiency (larger nets get better FX rates). The Treasury Service uses a dynamic windowing algorithm: for high-volume corridors (USD→INR, USD→MXN), netting windows are 5 minutes; for low-volume corridors, the window extends to 30 minutes or triggers when accumulated volume reaches $100K, whichever comes first.

Key Trade-offs

• Internal netting over per-transfer FX conversion: Netting opposing flows eliminates FX spreads entirely on matched amounts, dramatically improving margins — but requires sufficient bi-directional volume, limiting effectiveness to major corridors
• Rate locking for 30 seconds over dynamic rates: Guaranteed rates improve UX by eliminating surprise rate changes during checkout, but the platform assumes FX risk during the lock window — hedged by placing forward orders with liquidity providers
• Fuzzy sanctions matching over exact-only matching: Fuzzy matching catches name evasion attempts but generates 3-5% false positive rate requiring manual review — a dedicated compliance team reviews flagged transactions within 4 hours
• Multi-partner payout redundancy over single-partner per corridor: Having 2-3 payout partners per corridor enables automatic failover but increases integration maintenance cost — justified by the revenue impact of payout downtime