How the August 2024 selloff found brokerages’ capacity limit before the first trade

The week

When markets fall hard, investors do something very human: they reach for their phones to see how bad it is. On the morning of Monday, August 5, 2024, millions of them did exactly that, and many could not get in.

The backdrop was a sharp global selloff. A weak US jobs report the previous Friday combined with a rapid unwinding of trades funded in Japanese yen. Those trades, often called the yen carry trade, involve borrowing cheaply in yen and investing the money in higher-yielding assets elsewhere. When the yen rises or conditions shift, investors rush to close those positions at the same time, and selling feeds on itself.

The result was dramatic. Japan’s Nikkei 225, the country’s best-known stock index, fell about 12 percent, its worst day since 1987. The Cboe Volatility Index, often called the market’s “fear gauge” because it rises when investors expect big price swings, briefly reached its highest level since 2020. US stocks opened sharply lower and recovered over the following days.

That morning, customers of Charles Schwab, Fidelity and Vanguard reported trouble logging in and viewing balances, according to Reuters and other outlets citing outage-tracking sites, websites that collect reports from users when a service seems to be down. Schwab said a technical issue had been resolved shortly after midday Eastern time. Fidelity described intermittent issues that it said were fixed.

One detail is easy to miss and important to understand. Trading venues themselves operated normally. The stock exchanges and the systems that match buyers with sellers kept working. The bottleneck was not the market. It was the front door of the brokerages: the step of signing in and loading an account page, before anyone had placed a trade.

For many customers, that distinction did not matter in the moment. If you cannot see your account, you cannot decide whether to buy, sell or sit tight. For any organization with a customer-facing app, it raises a sharper question: when everyone shows up at once, which part of the system gives way first, and who is responsible for making sure it does not?

Retail brokerages build order routing and execution for bursts. Order routing is the machinery that takes a customer’s instruction to buy or sell and sends it to an exchange or other venue; execution is the trade actually happening. Those systems are designed with market spikes in mind, because a broker that cannot take orders in a crash has failed at its main job.

On August 5 the order path held. Customers struggled earlier, at signing in and loading the account page. Call it the pre-trade path: everything that has to work before a customer can decide to trade. On a stress morning every customer opens the app within the same hour, and most only want to look.

That is a different kind of load. A department store on the first morning of a big sale faces the same thing: the checkout lanes may be well staffed, but if the doors and the escalators jam, nobody reaches the tills. Brokerages had planned for the checkout lanes. The doors were the problem.

The rules leave the capacity target to the firm. Regulation SCI, which requires tested capacity at exchanges, clearing agencies and certain other market infrastructure, did not cover retail broker-dealers. The SEC had proposed in 2023 to extend it to some large broker-dealers, but that proposal was still pending. Broker-dealers had to keep a business continuity plan under FINRA Rule 4370 and supervise their systems, without a numeric standard for customer channels. FINRA is the industry’s self-regulatory organization, and a business continuity plan is a firm’s documented plan for keeping essential operations going during a disruption. Neither tells a firm how many logins per minute it must be able to handle.

The pre-trade path has three layers, each with a different owner: the identity layer, the account view and the shared vendors underneath both. First, a few of the building blocks.

What sits behind a login

Capacity. Every computer system can handle only so many requests at once. Capacity planning is deciding how much a system must handle on its busiest day, and load testing is a rehearsal with simulated users to find the point where it breaks.

Scaling. Modern apps usually run on cloud computing, where extra servers can be added when demand rises. But scaling up is not instant, and some components, such as databases or outside services, cannot simply be multiplied.

Hashing. Firms do not store customers’ passwords as plain text. They store a scrambled version, called a hash, and check each login by scrambling the typed password the same way and comparing. Good hashing is deliberately slow, so that a criminal who steals the scrambled versions cannot easily reverse them. That slowness is a security feature, but it means each login costs real computing work.

APIs and vendors. An app is rarely one system. It calls many other services through APIs, application programming interfaces, which are standard ways for one piece of software to ask another for something. Some of those services belong to outside vendors: the company that sends text-message codes, the one that supplies live prices, the cloud provider that hosts it all.

Content delivery networks and cloud regions. A content delivery network is a global set of servers that stores copies of a website’s images and pages close to users so that they load quickly. A cloud region is one of a cloud provider’s geographic clusters of data centers. Both sit under many firms at once.

The identity layer

A login at a brokerage is a chain of checks. The password is verified with a hashing method that is deliberately expensive in computing terms, so that stolen hashes are hard to crack. A risk engine, software that judges whether a login looks normal, scores the device and location. A one-time code may go out through an SMS aggregator, a company that sends text messages in bulk on behalf of businesses. A session token, a digital pass that keeps the customer signed in, is issued and stored. Each step has its own ceiling, and the security team usually owns them.

A stress morning also looks like an attack. Credential stuffing, in which criminals try huge lists of stolen usernames and passwords to see which ones work, produces a burst of logins from many sources, and so does a market drop. Bot defenses and rate limits, the tools that slow or block unusually heavy traffic, tuned for normal days can turn away legitimate customers just as volume peaks. Customers then retry, and apps may retry automatically, which multiplies load on a tier that is already saturated.

Firms have several options, each with a trade-off:

• Passkeys and app-based push approvals cut dependence on SMS delivery and are cheaper to verify at scale. A passkey lets a phone or computer prove the customer’s identity with a fingerprint or face scan instead of a typed password; a push approval is a tap on a notification in the firm’s own app.
• Longer sessions on trusted devices reduce the number of full logins on a stress day, at some cost in exposure if a device is stolen.
• A volatility mode for the risk engine relaxes some friction for known devices while holding it for new ones.
• Retry logic in the app should back off rather than hammer. If a request fails, the app should wait a little longer before each new attempt, rather than resending instantly.

On August 5 there was also warning time. The Nikkei fell during the US night, hours before the New York open. A pre-open trigger, such as an overseas index move or volatility futures spike, can start pre-scaling the identity tier before customers wake up.

The account view

Once signed in, most customers go straight to the portfolio page. It is often the most expensive page in the app. It pulls positions, applies real-time quotes to each holding, computes gains and losses, and may call for news and research content as well. On a normal day these calls are spread across hours. On a stress morning they arrive together, and the market data lookups multiply with every position held. A customer with forty holdings can generate forty price requests just by opening one page.

The engineering response is graceful degradation decided in advance. Graceful degradation means a system sheds its less important features under strain so that the essential ones keep working. Product and operations teams should agree a short list of features that can be switched off by flag when load crosses a threshold, such as charts, research panels, personalized content and non-essential calculations. A feature flag is a switch built into the software that lets a feature be turned on or off without releasing a new version of the app.

Positions can be served from a cache, a short-term store of recently fetched results, that refreshes every few seconds rather than on every request, with the timestamp shown. Order entry and order status must be protected above everything else, with their own capacity reserved.

When the platform still cannot keep up, a virtual waiting room with an honest estimate is better than error pages that invite refreshes. Many people have seen these when buying concert tickets: a page that says “you are in line, estimated wait four minutes.” A status page hosted outside the main platform, and a message pointing to phone trading where it exists, reduce call volume. They also give customers a record of what the firm said, which matters later if customers complain about trades they could not place.

The shared vendors

Under both layers sit services that the firm does not run: identity providers, content delivery networks, SMS aggregators, market data vendors and cloud regions. A market drop is a surge for every brokerage at once, so the shared vendors take the combined load of the whole industry. That correlation is easy to miss when each firm plans its own capacity. Each firm may be ready for three times its normal traffic; the vendor serving all of them may not be ready for three times everyone’s.

Vendor contracts tend to promise availability as a percentage of time, such as being up 99.9 percent of the month. Few state throughput, such as messages or requests per second that the vendor will sustain for this customer during a market-wide burst. Vendor management should ask for that number, test it jointly where possible, and confirm how the vendor rations capacity across clients.

Inside the firm, each external call on the pre-trade path needs three protections:

• A timeout, so the app stops waiting after a set period.
• A circuit breaker, which, like the electrical kind in a house, cuts off calls to a failing service for a while so it is not overwhelmed and the rest of the system is not dragged down.
• A fallback, a simpler alternative to use when the main service is unavailable.

A slow dependency can be worse than a dead one, because waiting requests tie up resources and trigger retries. A second channel for one-time codes and a second market data source for the portfolio page are the most common fallbacks worth paying for.

Setting the target, and who owns it

Each of the three layers needs a measurable target. A firm might set one as logins per minute at a stated multiple of its worst observed morning. Without a regulator setting the target, the board or risk committee is the natural place to approve it.

This is where leadership matters most. The identity layer belongs to security, the account view to product and engineering, and the vendors to procurement and vendor management. Each team can be doing its job well while the customer still cannot get in, because no one owns the end-to-end experience of “open the app on a bad morning and see my money.” A single, board-approved target for that journey forces the three owners to plan together.

One firm’s target, from approval to test

Take a mid-sized online brokerage. Its worst observed morning saw a certain peak of logins per minute. Its risk committee approves a target of three times that figure, sustained for an hour, from login through to a loaded portfolio page. To meet it, the security team adds push approvals and a volatility mode to its risk engine. Product agrees a kill list: charts, news and research panels go dark when load crosses a set level, and positions are served from a five-second cache with a visible timestamp. Vendor management asks the text-message provider and the market data vendor for committed throughput during industry-wide bursts, and adds a second provider for each. Operations sets an overnight trigger tied to overseas market moves. Once a year, the firm runs a full load test of the whole path and reports the result to the committee.

Each of these steps is ordinary. Together they turn “we hope the app holds up” into a target someone has signed.

The morning of greatest need

For a brokerage, the morning of a market shock is the moment of greatest customer need and greatest scrutiny. Customers who cannot see their accounts are anxious, and some will blame the firm for losses on trades they could not place. Those complaints carry legal and regulatory weight, and they shape reputation far beyond the day itself. Contact centers fill up when apps fail, adding cost at the worst possible time.

The pattern is not limited to brokerages. Banks see the same rush when news breaks about a bank in trouble. Health insurers see it during open enrollment. Government agencies see it when a benefit deadline approaches or a disaster strikes. In each case, most visitors only want to look, and the systems that let them look are rarely planned with the same care as the systems that process transactions.

There is a human dimension too. Customer service staff take the brunt of a front-door failure, fielding calls from frightened customers while having no better view of the problem than the customers do. A clear status page, scripted answers and a waiting room that gives honest estimates all make their jobs easier, and that shows in how customers remember the day.

Finally, there is the question of what a firm can show afterward. If a customer, a regulator or a court asks what the firm did to prepare, a board-approved target, a recent load test of the full path and documented vendor commitments are far stronger answers than a general statement that systems are monitored. Preparation that is written down, tested and reported is preparation that can be defended.

A target that fits in one sentence

A well-prepared firm can say, in one sentence, how many customers per minute it can sign in and show a portfolio to, and how that compares with its worst day. It has tested the full path as well as the individual pieces. It has a volatility mode, a kill list and a waiting room ready. It knows which vendors sit under the path and what each has committed to during a market-wide surge.

Firms fall short in familiar ways:

• load testing the trading engine but not the login and portfolio page;
• tuning bot defenses for normal days and never asking how they behave in a genuine rush;
• letting apps retry instantly and endlessly;
• treating every feature as essential, so nothing can be switched off;
• accepting vendor contracts that promise uptime but not throughput; and
• leaving the capacity target unowned because no rule requires one.

From worst day to signed target

1. On our worst day so far, how many customers tried to sign in per minute, and how many could we actually serve?
2. Have we load tested the whole journey from login to a loaded account page, or only parts of it?
3. How do our fraud and bot defenses behave when genuine customers arrive in a rush? Could they lock out real people?
4. Which outside vendors sit on the path to signing in and seeing a balance, and what throughput have they committed to during an industry-wide surge?
5. Who in the firm owns the end-to-end target, and has the board or risk committee approved it?

With hindsight

August 5 turned out to be less a turning point in markets than a stress test for the systems around them.

The selloff was short-lived. US indexes recovered their losses within weeks, and the episode is remembered as a volatility shock rather than a crisis. The access problems at Schwab, Fidelity and Vanguard were resolved the same day.

They also followed a familiar pattern, after retail platform strain in March 2020 and during the meme-stock surges of early 2021. Each time, the trigger was different, but the shape was the same: a sudden rush of customers wanting to look and act at once, and front-door systems that struggled to keep up. That repetition is itself instructive. A problem that recurs every few years points to a planning gap rather than bad luck.

On regulation, the gap described here widened rather than closed. On June 12, 2025, the SEC formally withdrew fourteen pending proposals, including the 2023 plan to expand Regulation SCI to some large broker-dealers and a proposed cybersecurity rule for broker-dealers.

Capacity for retail customer channels therefore remains governed by business continuity plans, supervision and customer expectations, not by a specific standard. No rule tells a brokerage how many logins per minute it must handle on a bad morning.

That leaves the target with each firm’s own risk governance, which gives boards and executives both a responsibility and an opportunity. A firm that sets its own clear, tested target for the pre-trade path, and holds its security, product and vendor teams jointly to it, does not need to wait for a rule. It can decide now what its customers will experience the next time markets fall overnight and everyone reaches for their phones at once.