What to Expect in the Ramp System Design Interview

Ramp's system design interview matches the company's engineering identity: pragmatic, fintech-grounded, and suspicious of architecture for its own sake. The prompts come from Ramp's actual surface area: card transaction processing, receipt matching, approval workflows, spend-policy engines, and the integration layer that connects corporate finance to banks, card networks, and accounting systems. The evaluation rewards a specific judgment profile: the design that ships this quarter with clean seams for next quarter, over the theoretically complete system that never lands.

Money-path fundamentals are assumed rather than taught: idempotency, reconciliation, and audit trails should be in your reflexes before this round, because the follow-ups build on them rather than testing for them.

The Question Territory

• Design a card authorization flow. The real-time heart of the product: a card swipe arrives from the network with a hard latency budget; check the card's controls (limits, merchant categories, per-transaction rules), the company's policy, and available balance, then approve or decline. Probes: what happens when the policy service is slow (fail open or closed, per control type), and how spend controls stay instantly consistent after an admin changes them.
• Design receipt matching. Ramp's automation showcase: match incoming receipts (email forwards, photos, integrations) to card transactions: fuzzy matching on amount, date, and merchant, confidence thresholds routing between auto-match and human review, and learning from corrections.
• Design an approval workflow engine. Spend requests routed through configurable approval chains: the durable state machine territory covered in our ServiceNow guidance, with fintech stakes.
• Design the accounting-sync layer. Reliable export of transactions to accounting systems: mapping rules, batch versus streaming sync, handling the customer's chart-of-accounts changes, and never double-booking: integration reliability as a first-class system.
• Design a spend analytics or anomaly-detection surface. Aggregations over transaction streams, policy-violation detection, and duplicate-subscription discovery: the read-side product built on the money data.

What Interviewers Are Probing

1. Latency-critical money decisions. Card authorization has a network-imposed budget (a couple of seconds end to end, of which your slice is small). Candidates who budget explicitly, precompute what can be precomputed (controls and balances hot in memory), and design the degraded path deliberately (which checks fail closed: fraud; which fail open with limits: a slow analytics enrichment) demonstrate the domain instinct.
2. Automation with confidence routing. Ramp's product thesis is automating finance work, and the house design pattern is confidence-tiered automation: high-confidence cases fully automatic, medium routed to lightweight human review, low escalated, with correction data feeding the thresholds. Recognizing when a prompt wants this shape (receipt matching, categorization, fraud) marks a candidate who understands the company.
3. Integration realism. Banks and accounting systems are slow, flaky, and occasionally wrong. Designs that treat external systems as unreliable dependencies (retries with idempotency, reconciliation jobs as the source of truth, and explicit handling for the partner being down for a day) fit Ramp's operating reality.
4. Pragmatic sequencing. The follow-up "what would you build first with two engineers?" is close to guaranteed in spirit. Have a build order with reasons: the transactional core first, automation second, analytics last.
5. Multi-tenant policy isolation. Every customer configures controls differently; policy evaluation must be correct per tenant, fast, and cache-consistent when admins change rules. The invalidation story gets probed.

Walkthrough Sketch: The Card Authorization Path

Requirements first: authorizations arrive from the card network with roughly a two-second total budget (your decision slice: low hundreds of milliseconds), volume spikes at business hours, and a wrong approve is real money while a wrong decline is a customer standing at a register embarrassed: both costs named, because the tradeoff shapes everything. The hot path must not do slow work: precompute and cache per-card state (limits, category rules, remaining balances) in a memory tier, updated via change streams from the policy and ledger systems, so the authorization decision is a local evaluation, not a fan-out of service calls.

The decision engine evaluates deterministic rules first (card frozen, limit exceeded, category blocked: instant declines), then policy checks, then risk scoring with a strict time box: if the risk model misses its budget, fall back to rule-based limits rather than blocking the path. Write the authorization record before responding (idempotent on the network's transaction ID, because retries happen), emit events for downstream (receipt matching, analytics, accounting sync), and reconcile continuously against the network's settlement files, which are the eventual truth: authorizations and settlements disagree routinely, and the reconciliation job is where correctness actually lives. Failure modes with the pragmatic lens: cache staleness after an admin tightens a limit (bound it: change streams target sub-second propagation, and the reconciliation catches leakage), the risk service down (time-boxed fallback already designed), and a network retry storm (idempotency keys make it noise). Close with the build order: rules engine and idempotent recording first, risk scoring second, streaming policy propagation third, because the first slice alone is a shippable, safe product.

How to Prepare

• Foundations and money fundamentals: Grokking the System Design Interview and Grokking System Design Fundamentals for the base; Advanced System Design Interview, Volume II for consistency and failure depth; and the idempotency-reconciliation-audit vocabulary until fluent.
• Rehearse the two house designs: card authorization (latency-budgeted money decisions) and receipt matching (confidence-tiered automation), end to end. Their patterns cover most of Ramp's territory.
• Practice the build-order close. End every practice design with the two-engineer sequencing; at Ramp the pragmatism is scored.
• Borrow the adjacent prep: our Stripe and Robinhood system design answers cover the shared fintech register; Ramp adds the automation and integration accents on top.

For the full loop, see What is the Ramp interview process like?, and prepare the tiny-CEO screens with Top Ramp behavioral interview questions and your answer to "Why Ramp?"