Build a Transfer-Fee Comparison Prototype

Product Scenario

Cross-border money transfer platforms need to display accurate, transparent price comparisons across competing services for specific remittance corridors (e.g., USD to PHP, EUR to INR). Comparing transfer costs requires accounting for both upfront transaction fees and hidden exchange rate markups relative to the interbank mid-market rate.

You are asked to design an end-to-end prototype and architecture for a fee-comparison engine that aggregates pricing from external provider APIs, public web flows, and third-party data partners, normalizes total customer cost, and serves these comparisons to end-users and internal pricing tools.

Requirements

Functional Requirements

• Quote Ingestion & Normalization: Support queries for a given corridor (source_currency, target_currency, send_amount, delivery_method). Compute: Total Cost = Upfront Fee + (Send Amount * (1 - Provider Rate / Mid-Market Rate)).
• Provenance & Auditability: Every quote must retain source identifier, retrieval timestamp, expiration TTL, and a reference to the raw response payload.
• Partial Availability & Failure Handling: If a provider API or scraper times out, rate limits, or fails, the system must return partial comparisons while explicitly flagging unavailable or stale quotes rather than failing the entire request.
• Extensibility: Adding a new provider integration or fallback parser should require minimal code changes.

Non-Functional Requirements

• Latency: P95 comparison response under 800ms for cached/pre-warmed corridors; on-demand live fetching should not exceed 3 seconds.
• Freshness: FX quotes must not be older than 5 minutes during active market hours.
• Compliance & Transparency: Disclose fee breakdowns clearly without masking provider disclaimers or tiered promotional rates.

Scale & Operational Assumptions

• 100 active corridors across 20 distinct providers.
• 3,000 comparison requests per minute during peak volume.
• Interbank mid-market reference rates are updated every 30 seconds from trusted financial feeds.

Key Design Deliverables

1. Data Model: Schemas for quotes, provider adapters, raw payloads, and normalized comparisons.
2. Component Architecture: Ingestion pipeline (APIs vs. web scrapers), caching strategy, worker pools, and fallback mechanisms.
3. Failure & Staleness Semantics: How API clients identify stale data vs. live data vs. failed provider queries.
4. Production Readiness: Rate-limiting defense, circuit breaking, observability, and automated validation for broken provider parsers.