Every time a customer swipes a card abroad, sends money to a relative in another country, or buys something priced in a foreign currency, two numbers exist for that transaction: the price the market would give a large institutional trader (the mid-market rate), and the price the customer actually gets. The gap between the two is the FX markup — and for decades, that gap was invisible. Banks and card networks folded it into a single “exchange rate” line, and customers had no easy way to know whether they had paid a 0.5% spread or a 6% spread.

That opacity was profitable, but it created a trust problem. Around the mid-2010s, a new generation of payment companies — largely born out of the remittance and neobank space — began advertising the mid-market rate itself as a marketing weapon: “we show you the real rate, then charge a transparent fee on top.” This forced an industry-wide shift. Regulators followed. The European Union’s Cross-Border Payments Regulation and PSD2 disclosure rules, India’s RBI guidelines on card markup disclosure, and various U.S. state-level remittance disclosure laws (modeled on the Dodd-Frank Act’s Remittance Transfer Rule) began to require that payment providers disclose the exchange rate used and the total cost of a transfer before the customer confirms it.

This regulatory and competitive pressure turned “show me the markup” from a nice-to-have UX feature into a hard, real-time, high-availability system requirement. The system has to answer a very specific question, correctly, in under a few hundred milliseconds, for every currency pair a platform supports, at global scale: “If I convert X units of currency A to currency B right now, what is the mid-market rate, what is the rate I’m actually getting, and what does that cost me in absolute and percentage terms?”

1.1 What “fee transparency” actually means as a system requirement

It is tempting to think of this as “just show two numbers and subtract them.” In practice, the requirement decomposes into several distinct engineering problems:

• Sourcing a defensible mid-rate — pulling live rates from one or more market data providers and defining, unambiguously, what “the mid rate at this instant” means.
• Applying a markup policy — the platform’s own pricing logic, which may vary by currency pair, customer tier, transaction size, payment corridor, or promotional campaign.
• Presenting it before commitment — the customer must see the breakdown pre-transaction, not buried in a statement afterward, and the rate they see must be honored (often called rate lock or quote guarantee) for a short window.
• Recording it for audit — regulators and internal compliance teams need an immutable record of exactly what rate and fee were shown and charged, for every transaction, for years.
• Doing all of the above under extreme load and extreme rate volatility — during market-moving events (central bank announcements, geopolitical shocks), rates can move multiple times per second, and the system must not show stale or contradictory numbers.

On the surface this looks like a simple arithmetic and display problem. It is not, for four structural reasons.

2.1 The mid-rate itself is not a single number

“The market rate” is a fiction of convenience. In reality, for any currency pair, dozens of liquidity providers and exchanges are quoting slightly different bid and ask prices at any given moment, and those quotes are themselves moving continuously. A defensible “mid rate” is actually a derived, aggregated value — typically the midpoint between the best bid and best ask across a curated panel of providers, sometimes volume-weighted, sometimes simply averaged, refreshed on a fixed cadence (commonly every 1–10 seconds for major pairs, less frequently for exotic pairs). The system design challenge is building a pipeline that ingests multiple noisy, sometimes conflicting, sometimes momentarily unavailable feeds and produces one trustworthy number the whole platform agrees on.

2.2 Markup policy is a pricing engine, not a constant

A naive implementation assumes “we always add 1% markup.” Real platforms vary the markup by dozens of dimensions: the currency pair (exotic pairs often carry wider spreads because they’re less liquid and riskier to hedge), the transaction size (large transfers sometimes get tighter spreads because they’re more profitable in absolute terms, or wider spreads because they carry more hedging risk), the customer’s tier or loyalty status, the payment corridor and rail (a card transaction settling through a card network has different economics than a bank-to-bank wire), promotional campaigns, and even the time of day relative to market liquidity. This means the “fee” isn’t a constant lookup — it’s the output of a rules or pricing engine that must be evaluated per-quote, consistently, and explainably.

2.3 Regulatory disclosure has hard legal definitions

Different jurisdictions define what must be disclosed differently. Some require disclosure of the “total cost” as a single combined percentage. Others require the mid-market rate to be shown explicitly and separately from any flat fee. Some remittance regulations require the disclosure to remain valid and honored for a fixed period (commonly referred to as a rate-lock or quote-validity window) even if the market moves against the platform in that window. Getting this wrong is not just a UX bug — it is a compliance violation with real regulatory penalties.

2.4 Scale and volatility compound each other

A payments platform processing millions of requests per minute across hundreds of currency pairs cannot afford to compute a fresh markup from scratch, synchronously, against a live upstream FX provider on every single customer request — the upstream providers themselves rate-limit and charge per API call, and the added network hop would blow latency budgets. The system must therefore separate the expensive, infrequent work (ingesting and aggregating raw market rates) from the cheap, frequent work (serving a quote to a customer), while still guaranteeing the served quote reflects a rate that is fresh enough to be legally and financially defensible.

The system splits cleanly into two planes: a rate ingestion plane that continuously builds a trustworthy, cached view of mid-market rates, and a quote-serving plane that combines that cached rate with the platform’s pricing policy to answer a customer’s request in real time. A third, cross-cutting concern — audit and ledger recording — ties every served quote to an immutable record.

4.1 How the mid-rate is computed

For a currency pair like USD/INR, the aggregator maintains a small in-memory window of the most recent valid ticks from each subscribed provider. On each refresh cycle it:

1. Discards any tick older than the configured freshness threshold (for example, 5 seconds for major pairs).
2. Computes each provider’s implied mid-point as the average of their bid and ask.
3. Combines the surviving provider mid-points using the platform’s chosen aggregation function (simple mean, weighted mean by provider reliability score, or median to reduce outlier influence).
4. Runs a delta check against the previously published rate — if the new rate has moved more than a configured circuit-breaker threshold in one cycle, it is flagged for review rather than published blindly, since a huge single-cycle jump is more likely a bad feed than a real market move.
5. Publishes the accepted rate to the cache with a monotonically increasing sequence number and a timestamp.

4.2 How a customer quote is computed

When a customer opens a currency conversion screen or a transaction is being priced at checkout, the FX Quote Service performs, in order:

1. Cache read — fetch the latest published mid-rate for the requested pair from the rate cache. This is an in-memory lookup, typically completing in under a millisecond.
2. Freshness check — verify the cached rate’s timestamp is within an acceptable staleness bound. If the rate is too old (meaning the ingestion pipeline has fallen behind or a provider outage has starved the cache), the service either falls back to a secondary rate source or degrades gracefully by informing the client the rate is temporarily unavailable rather than serving a stale, misleading number.
3. Context resolution — determine the request’s pricing context: customer tier, transaction amount, corridor, and channel.
4. Markup calculation — the pricing engine evaluates the applicable rule and returns a markup expressed as a percentage (or sometimes a combination of a percentage spread plus a flat fee).
5. Customer rate derivation — the customer-facing rate is computed as the mid-rate adjusted by the markup in the direction that favors the platform (for example, mid-rate minus markup-percent for a sell-side conversion).
6. Quote assembly and lock — a structured quote object is built containing the mid-rate, the customer rate, the markup in both percentage and absolute currency terms, and — if the platform offers rate-lock — a quote ID and expiry stored in the lock store.
7. Audit emission — the full quote, including which mid-rate sequence number and which pricing rule version were used, is emitted as an event for the audit trail, before the response is returned to the client.

4.3 The fee transparency calculation, explicitly

The customer-facing markup disclosure typically needs three numbers displayed together:

The percentage markup is typically computed as $text{markup%} = (r_{mid} – r_{cust}) / r_{mid}$ for a sell-side conversion, and the absolute cost is $text{cost} = text{markup%} times text{amount} times r_{mid}$, expressed in whichever currency is most meaningful for the customer to understand (usually the currency they’re paying in).

public Quote buildQuote(QuoteRequest req) {
    RateSnapshot mid = rateCache.get(req.pair())
        .orElseThrow(() -> new RateUnavailable(req.pair()));
    ensureFresh(mid, freshnessBudget(req.pair()));

    PricingContext ctx = context.resolve(req);
    Markup markup = pricingEngine.evaluate(req.pair(), ctx);

    BigDecimal customerRate = mid.value()
        .multiply(BigDecimal.ONE.subtract(markup.percent()));
    BigDecimal absCost = markup.percent()
        .multiply(req.amount())
        .multiply(mid.value());

    String quoteId = quoteLock.reserve(req, mid, customerRate, LOCK_TTL);
    auditBus.emit(new QuoteIssued(quoteId, mid.sequence(), markup.ruleVersion(),
                                  customerRate, absCost, Instant.now()));

    return new Quote(quoteId, mid.value(), customerRate, markup.percent(),
                     absCost, LOCK_TTL);
}

5.1 Lifecycle of a rate, end to end

It helps to trace one rate value through its entire life to understand why the architecture is split the way it is:

1. Origination — a market data provider publishes a bid/ask tick for a currency pair, delivered over a streaming connection (WebSocket or a persistent gRPC stream) or a fast-polling REST endpoint.
2. Normalization — the provider adapter converts the vendor-specific payload into the platform’s internal tick schema.
3. Validation — the tick is checked against sanity bounds and deduplicated against the provider’s previous tick.
4. Aggregation — the aggregator combines this tick with the latest valid ticks from other providers into one published mid-rate.
5. Publication — the new mid-rate is written to the shared cache, replacing the previous value, tagged with a sequence number and timestamp, and simultaneously appended to a time-series history store.
6. Consumption — one or many quote requests, arriving concurrently across the globe, read this same cached value.
7. Markup application — the pricing engine transforms the mid-rate into a customer rate per request context.
8. Disclosure — the quote, containing both numbers and the delta, is returned to the client for display.
9. Optional lock — if the platform guarantees the quote, it is reserved with a short TTL.
10. Execution or expiry — the customer either confirms within the window (the locked rate is honored) or lets it expire (a fresh quote must be requested).
11. Audit persistence — every step from aggregation through execution is durably logged for compliance and reconciliation.

5.2 Handling concurrent requests against the same rate

Because the rate cache is read-only from the perspective of the quote-serving plane, thousands of concurrent quote requests for the same currency pair simply perform independent, non-blocking reads of the same cached value — there is no write contention on the hot path. The only place writes and reads interact is the rate cache’s own replacement of the value on each ingestion cycle, which is designed as an atomic set operation so no reader ever observes a partially updated rate.

6.1 Advantages of this architecture

• Decoupled cost profile — expensive upstream market data calls happen on a fixed schedule regardless of customer traffic, so a spike in customer requests never increases upstream API cost or rate-limit pressure.
• Predictable low latency — because quote serving only touches an in-memory cache and a rules engine, response times stay in the tens of milliseconds even under heavy load.
• Independent scalability — the ingestion plane and the serving plane can be scaled on entirely different dimensions: ingestion scales with the number of currency pairs and providers, serving scales with customer traffic.
• Auditable and explainable — every quote carries a reference to the exact mid-rate sequence number and pricing rule version used, making regulatory audits and customer dispute resolution tractable.
• Configuration-driven pricing — markup policy changes do not require a deployment, which shortens the cycle for pricing and compliance teams.

6.2 Disadvantages and costs

• Freshness versus cost tension — pulling tighter, more frequent updates from market data providers costs more and adds ingestion load; looser refresh intervals save cost but widen the window during which a served quote might diverge from the true live market.
• Rate-lock financial risk — honoring a quoted rate for a fixed window means the platform, not the customer, absorbs adverse market movement during that window; this must be modeled and hedged, or the lock windows kept intentionally short.
• Complexity of a multi-provider aggregation pipeline — building robust outlier detection and fallback logic across several vendors is materially harder than a single-source integration, but a single source is a single point of failure and manipulation risk.
• Regulatory divergence — different markets require different disclosure formats and different rate-lock durations, pushing complexity into the pricing and disclosure configuration layer.

6.3 Key trade-off table

At the scale described in the brief — millions of requests per minute — the design goal is that quote serving never performs synchronous work proportional to the cost of sourcing a fresh market rate. Every quote request should resolve through cache reads and in-process rule evaluation only.

7.1 Read path optimization

• In-memory cache colocated with compute — the FX Quote Service instances keep a local, short-TTL in-process copy of the hottest currency pairs, backed by the shared Redis cluster, cutting network round trips for the most frequently requested pairs (major pairs like USD/EUR, USD/INR, GBP/USD dominate volume disproportionately — a classic long-tail distribution).
• Read replicas for the shared cache, distributed across availability zones, so no single cache node becomes a bottleneck under fan-out read load.
• Pre-computed rule evaluation — for the most common pricing contexts (default tier, standard corridor), the pricing engine can pre-resolve and cache the effective markup percentage, only falling back to full rule evaluation for less common contexts.

7.2 Write path optimization

• Batched, sharded ingestion — currency pairs are sharded across aggregator instances so no single instance needs to process every tick from every provider for every pair.
• Backpressure-aware provider adapters — if a provider’s feed spikes in volume during high volatility, adapters apply local buffering and coalescing (only the latest tick per pair matters for mid-rate purposes) rather than forwarding every intermediate tick downstream.

7.3 Horizontal scaling model

The FX Quote Service is stateless with respect to customer requests (all state lives in the cache and lock store), which means it scales horizontally behind a load balancer with no sticky-session requirement. The rate cache scales via standard partitioning (sharding currency pairs across cache nodes) combined with read replicas per shard.

7.4 Latency budget example

8.1 Provider redundancy

No single market data vendor should be a single point of failure. The provider adapter layer subscribes to at least two, typically three, independent providers per major currency pair, and the aggregator is designed to keep publishing valid rates even if one provider’s feed drops entirely — it simply aggregates over the remaining healthy providers and flags reduced confidence internally.

8.2 Stale rate fallback strategy

If every provider for a pair becomes unavailable, the system must decide between three fallback behaviors, and this decision should be explicit, configurable, and tested:

• Serve the last known good rate with a visible staleness indicator, up to a maximum allowed staleness window.
• Widen the markup temporarily to compensate for increased market risk during the outage, rather than freezing the price entirely.
• Block new quotes for the affected pair entirely once staleness exceeds a hard threshold, rather than risk showing a materially wrong price — this is the safest default for compliance-sensitive markets.

8.3 Multi-region deployment

Each region runs its own full ingestion pipeline independently (not just a read replica of one master region), because relying on a single region to compute the authoritative rate for the entire globe creates a cross-region latency and single-point-of-failure problem. Instead, each region aggregates from the same provider pool and should converge on nearly identical rates given the same inputs and aggregation logic; small, expected divergence between regions is tolerated within a defined bound, and monitored.

8.4 Graceful degradation under partial outage

If the pricing engine’s rules service becomes unavailable, the FX Quote Service should fall back to the last successfully cached pricing rule set for that context rather than failing the entire quote request — a stale-but-valid markup rule is far less harmful than an outright quote failure at checkout.

9.1 Protecting the rate pipeline from manipulation

A currency rate feed is a high-value target: an attacker who can inject a manipulated tick, or exploit a race condition in the aggregation logic, could cause the platform to systematically mis-price conversions in their favor. Defenses include cryptographically signed feeds from market data providers where supported, strict schema and bounds validation on every incoming tick, outlier rejection against a multi-provider consensus, and full immutable logging of every tick that influenced a published rate so any anomaly is traceable after the fact.

9.2 Securing the quote and pricing APIs

• Authentication and authorization on every quote request, tied to the requesting customer or partner identity, since pricing context (tier, promotions) directly affects the markup applied.
• Rate limiting per client to prevent quote-scraping abuse, where a bad actor repeatedly requests quotes to reverse-engineer the platform’s exact pricing rules or to arbitrage momentary rate discrepancies across regions.
• Quote lock tokens must be single-use, tied to the requesting customer session, and validated server-side at execution time to prevent replay or transfer of a locked favorable rate to another transaction.
• Encryption in transit for all API traffic (TLS), and encryption at rest for the audit store, since transaction-level financial data is highly sensitive.

9.3 Preventing internal pricing rule abuse

Because markup rules are externalized as configuration for agility, that configuration surface itself becomes a security-sensitive asset — an unauthorized or accidental change to a pricing rule (for example, zeroing out markup on a corridor) directly costs the business money. Changes should go through the same rigor as code deployment: peer review, staged rollout, and full audit logging of who changed what rule and when.

9.4 Compliance-driven security requirements

Because this system handles financial transaction pricing, it typically falls under PCI-DSS scope (if card data touches any part of the flow) and regional financial data protection regulations. The audit store, in particular, must satisfy immutability and retention requirements — commonly implemented with write-once storage semantics or append-only ledger patterns, so historical quotes cannot be altered after the fact even by administrators.

10.1 What must be monitored

10.2 Alerting strategy

• Hard alerts (page immediately) — rate staleness beyond the legal disclosure threshold; all providers for a major pair simultaneously unavailable; audit event publish failures.
• Soft alerts (dashboard/ticket) — single provider feed degraded but others healthy; markup distribution drifting outside expected historical bounds, which may indicate a misconfigured pricing rule.

10.3 Logging and traceability

Every served quote is logged with a full trace: which mid-rate sequence number was read, which providers contributed to that rate, which pricing rule version was applied, and the resulting customer rate and fee. Distributed tracing (for example, OpenTelemetry spans propagated from the API gateway through the quote service, pricing engine, and cache) makes it possible to reconstruct exactly why a given customer saw a given price, which is essential both for engineering debugging and for answering a regulator’s or customer’s dispute.

11.1 Deployment topology

The ingestion plane and serving plane are deployed as independently scalable microservice clusters, typically on Kubernetes, with separate horizontal pod autoscaling policies — the serving plane scales on request rate and CPU, while the ingestion plane scales primarily on the number of actively tracked currency pairs and provider connection count.

11.2 Provider connectivity

Persistent streaming connections to market data providers (WebSocket or gRPC streams) benefit from being deployed close to the provider’s point of presence to minimize feed latency, sometimes justifying a dedicated ingestion deployment in a specific cloud region even if customer traffic is served globally.

11.3 Blue-green and canary rollouts for pricing logic

Because pricing rule changes directly affect revenue and compliance, deployments of the pricing engine (and especially rule configuration changes) go through canary rollout — a small percentage of traffic evaluated against the new rule set, with automated comparison of the resulting markup distribution against the previous baseline, before full rollout.

11.4 Infrastructure as code and config management

Given how central externalized pricing configuration is to this system, that configuration is itself version-controlled (often in a dedicated config repository with its own review and approval workflow, separate from application code) and deployed through a controlled pipeline rather than edited directly in a database by hand.

12.1 Storage choices

12.2 Why not just one database

A single relational database could theoretically hold all of this, but it would force the same storage engine to simultaneously serve sub-millisecond hot reads for currency rates and durable, strongly consistent writes for financial audit records — two very different access patterns with different consistency and latency requirements. Splitting them lets each store be tuned and scaled for its actual workload: the cache favors availability and speed with brief staleness tolerance, while the audit store favors durability and correctness over raw speed.

12.3 Caching strategy in depth

• Write-through on ingestion — the aggregator writes the newly computed rate directly into the cache as the authoritative update, rather than the cache lazily pulling from a database on a miss.
• No cache invalidation race — because rates are always replaced wholesale with a new value plus sequence number rather than partially mutated, there’s no classic cache invalidation problem; the latest write simply wins, and readers can detect if they’re looking at an old sequence number.
• Local process cache as a second tier — an in-process, very short TTL cache inside each Quote Service instance for the hottest pairs reduces network calls to the shared cache under extreme load, at the cost of very slightly increased staleness (bounded to a few hundred milliseconds).

12.4 Load balancing

The FX Quote Service sits behind a standard Layer 7 load balancer using round-robin or least-connections distribution, since instances are stateless. Global traffic is additionally routed via GeoDNS or an anycast-based global load balancer to the nearest healthy region, both to minimize latency and to provide automatic regional failover if an entire region’s serving cluster becomes unhealthy.

13.1 Core API surface

POST /v1/fx/quotes
{
  "sourceCurrency": "USD",
  "targetCurrency": "INR",
  "amount":         100.00,
  "corridor":       "US_TO_IN",
  "channel":        "app"
}

Response 201:
{
  "quoteId":       "Q-9931",
  "midRate":       83.10,
  "midSequence":   48210,
  "customerRate":  82.60,
  "markupPercent": 0.6019,
  "markupAbsolute": { "amount": 50.00, "currency": "INR" },
  "expiresAt":     "2026-08-11T09:00:45Z",
  "ruleVersion":   "v12"
}

POST /v1/fx/executions
{ "quoteId": "Q-9931" }

Response 200:
{
  "executionId":  "X-77a1",
  "quoteId":      "Q-9931",
  "finalRate":    82.60,       // honored from the locked quote
  "settledAt":    "2026-08-11T09:00:12Z"
}

13.2 Microservice boundaries

Each of the following is deployed as an independently owned, independently deployable service, communicating over well-defined APIs and asynchronous events rather than shared databases: Provider Adapter services (one logical service per vendor integration, or a shared service with per-vendor plugins), the Rate Aggregator, the Rate Cache (infrastructure, not a custom service), the Markup Pricing Engine, the FX Quote Service (the customer-facing orchestrator), the Quote Lock service, and the Audit/Ledger service. This separation lets each team iterate and scale their piece independently — a new market data provider integration should never require touching the pricing engine’s code.

13.3 Synchronous versus asynchronous communication

The customer-facing quote request path is synchronous end to end because the customer is waiting for a response in real time. Everything downstream of “quote has been decided” — audit logging, analytics, fraud signal enrichment, notification triggers — is asynchronous, published as events onto the event bus, so none of it adds latency to the customer-facing response and none of it can cause a quote request to fail due to an unrelated downstream hiccup.

13.4 API versioning and backward compatibility

Because partner integrators and mobile app versions in the wild can lag behind the latest API contract by months, the quote API is versioned explicitly, and changes to the disclosed fee breakdown format (a compliance-sensitive payload) go through a deprecation window rather than a breaking change, since older app versions must continue to display accurate, correctly labeled fee information.

14.1 Patterns applied

14.2 Anti-patterns to avoid

15.1 Best practices

• Always show both numbers, never just the delta. Displaying “you paid a 0.6% fee” without showing the actual mid-rate and customer rate side by side is a weaker transparency signal and easier to distrust; showing all three builds credibility.
• Version every pricing rule and every published rate. This is what makes the system auditable and disputes resolvable months later.
• Define staleness thresholds explicitly, per currency pair, and enforce them in code, not just policy documents. Exotic, thinly traded pairs may reasonably tolerate looser thresholds than major pairs.
• Treat pricing configuration changes with the same rigor as code deployments — review, staged rollout, rollback plan.
• Design the disclosure format to be jurisdiction-configurable from day one rather than retrofitting it later, since global payment platforms almost always end up needing per-market disclosure variants.
• Make the rate-lock window a tunable parameter, not a constant, so it can be adjusted per corridor based on observed volatility and hedging cost.

15.2 Common mistakes

• Confusing “mid-rate” definitions across teams. If the aggregation methodology isn’t precisely documented and shared, different parts of the platform (marketing pages, statements, in-app quotes) can end up displaying subtly different “mid rates,” undermining trust even though nothing is technically wrong.
• Ignoring rounding and currency-decimal-precision edge cases. Currencies have different standard decimal precisions (Japanese Yen typically has zero decimal places, most others have two, some have three), and inconsistent rounding between the mid-rate display and the actual charged amount produces visible, confusing discrepancies of a fraction of a currency unit.
• Under-provisioning the audit pipeline relative to the serving plane. If quote serving scales to handle a traffic spike but the audit event pipeline doesn’t, a backlog builds silently and compliance data lags behind, sometimes for hours.
• Testing the pricing engine only with “happy path” contexts. Edge cases — a customer whose tier changes mid-session, a currency pair added mid-day, a promotional rule with an ambiguous precedence versus a standard rule — are where markup calculation bugs actually surface in production.

16.1 Common threads across these systems

• They all separate a continuously updated market data layer from a per-request pricing decision.
• They all treat the disclosed fee breakdown as a compliance-grade artifact, not just a UI nicety.
• They all handle multiple, sometimes conflicting, market data sources rather than trusting a single vendor blindly.
• They all need the pricing logic to be adjustable by non-engineering teams without slowing down to a full software release cycle.

17.1 Key takeaways

• Fee transparency is fundamentally a two-plane system: a rate ingestion pipeline that builds a trustworthy cached mid-rate, and a quote-serving layer that applies markup policy per request.
• The mid-rate itself must be treated as an aggregated, validated, versioned value from multiple providers — never trusted from a single unvalidated source.
• Markup policy belongs in externalized, versioned configuration evaluated by a rules engine, not hardcoded in application logic.
• Rate-lock guarantees are a financial risk decision as much as a UX one, and should be explicit, bounded, and tunable per context.
• Every served quote needs full audit traceability — which rate, which rule version, which provider inputs — to survive regulatory scrutiny and customer disputes.
• Freshness, staleness fallback, and multi-region consistency all need explicit, tested policies rather than implicit assumptions, especially during high-volatility market events.