What Happens When an Acubic Rebalance Fails?

Key takeaways

• A broker rejection affects one order, not the whole rebalance: the other orders in the run continue and nothing already submitted is rolled back.
• Every rejection is recorded in the audit log with the broker's own stated reason, next to the fills from the same run.
• The usual causes are an instrument that is suspended or unavailable, or an order below the broker's minimum size. Market hours are handled before any order is sent: on both eToro and Trading 212, Full Automatic runs wait for the US regular session.
• Rejected orders are not retried within the same run. The next scheduled rebalance recalculates from your live positions and includes any drift that remains.
• A separate pre-trade sanity check can stop a whole run before anything is sent, if the calculated trades look implausible against the managed value.

When you set a rebalancing schedule on a live brokerage account, one of the questions that follows is what happens when an order does not go through. Brokers reject orders: an instrument goes temporarily unavailable, a position falls below a minimum size. These are routine events in any automated system operating at scale, and the thing that matters is not whether they occur but what the system does about them. Does a single rejection take down the whole rebalance? Is it recorded somewhere you can review, or does the run move on as if nothing happened?

This article answers those questions directly. The failure behavior is documented in the broker connection guides for both supported brokers, so the answers are drawn from published on-site material rather than from inference.

An order rejection affects one position, not the whole run

The most important thing to understand about a rejected order in an Acubic rebalance is that it is isolated. When a broker refuses one order in a rebalance run, the remaining orders in that run continue independently. A single rejection does not cascade to the other positions. The run does not stop, and it does not roll back any orders that have already submitted.

This is a deliberate design choice rather than an incidental one. The alternative, aborting the entire run on the first rejection, can seem cautious but produces worse outcomes in practice. A rebalance that corrects ten of eleven positions has meaningfully reduced the drift in the portfolio. A rebalance that corrects nothing, because one instrument failed and the whole run stopped, leaves the portfolio in the same uncorrected state it was in before the run fired. Acubic's approach handles the positions it can and records the one it could not, rather than treating a partial failure as a total one.

The drift on an uncorrected position does not disappear. It remains in the portfolio until the next scheduled run, at which point the construction process reruns from scratch against the live position set and includes that position in the new order set if the drift is still present. The article on what triggers an Acubic rebalance explains how the construction reruns on each date and why the target allocation is derived fresh each time rather than locked in from initial setup.

What causes a broker to reject an order

Two situations account for most rejections in Acubic's execution history, and a third, market hours, is handled before any order is sent.

An instrument becomes unavailable. A stock can be suspended, delisted, or temporarily removed from a broker's platform between the moment Acubic reads your live positions and the moment the order is submitted. Regulators can also stop trading outright: in the United States, "The federal securities laws allow the SEC to suspend trading in any stock for up to 10 trading days" (SEC, Trading Suspensions), and exchanges halt individual stocks for shorter periods. When that happens, the broker returns a rejection at the instrument level. The order for that position is recorded as failed; the orders for all other positions in the same run continue.

Market hours are handled before submission, not by a rejection. On both eToro and Trading 212, a Full Automatic run that comes due while the US regular session is shut is deferred to the next open rather than run, and the schedule is not used up by the deferral. The session Acubic uses is the New York Stock Exchange's core session, "9:30 a.m. to 4:00 p.m. ET" on weekdays, minus NYSE market holidays, of which the exchange lists ten full-day closures in 2026 (NYSE, Holidays and Trading Hours). One-Click Approval plans can be prepared and sent to you at any time, and what happens when you approve one outside market hours depends on the broker. On eToro the approval goes through and eToro queues the out-of-hours orders until the market opens rather than rejecting them. On Trading 212, Acubic places nothing outside the US regular session: the approval returns a “markets are closed” message with the time of the next open, nothing is sent, and the plan stays pending so you can approve it again once the market is open.

A position falls below a minimum order size. Brokers impose minimum thresholds on the size of individual orders, and a position targeted for a small correction may produce an order that falls below that threshold. The broker refuses it rather than partially executing it, and the rejection is attributed to that position in the run.

In each case, the cause is specific to the position, not to the run as a whole. The other positions are not affected.

The audit log captures rejections alongside fills

Acubic records every order it places in an audit log, and that includes rejections. The failure is not summarised or dropped: it is recorded against the specific rebalance run with the broker's own stated reason. That is the error message the broker returned, not Acubic's interpretation of it. After any run, you can review what filled, what did not, and what reason the broker gave for each rejection, in the connection's execution history.

The audit log is on regardless of which automation mode you are using. One-Click Approval, Full Automatic or Manual: the recording behavior is the same. In Manual mode Acubic places no orders, so there is nothing to record, but in one-click and full-auto every submitted order, every fill, and every rejection appears in the log.

The reason this matters is not tidiness. An automated system acting on an account that holds real money is only trustworthy if you can reconstruct what it did and why, after the fact. A log that records only successful fills does not let you audit a run that had failures. The log records both.

How automation mode shapes what you see

The behavior when an order is rejected is the same in one-click and full-auto modes. What differs is when you become aware of it and what you saw before the run executed.

In one-click approval mode, the rebalance is prepared and then stops before any order is sent to the broker. You review the proposed set of trades and approve or reject them as a batch. If you approve, the orders go out, and any rejections the broker returns during submission are recorded in the audit log. You can check the outcome after the run completes. If you chose not to approve the run, no orders were sent and no rejections are possible: an unapproved run in one-click mode is not a failure, it is the expected outcome of that mode. The detail on what each mode does at each step is in the article on one-click vs full-auto rebalancing.

In full-auto mode, the scheduler prepares and submits the order set without a per-order prompt. You are not present at the moment of execution. Any rejections appear in the audit log and will be visible the next time you review the connection's execution history. The safety guards in full-auto do not change how individual rejections are handled: one order executes at a time, position sizing rounds down rather than up, and the same treatment of isolated failures applies. Full-auto does not remove the recording of rejections or change their independence from other orders in the run.

What connects both modes is the audit log. The record of what happened is there regardless of whether you were watching when it happened.

The sanity check is a different mechanism

There is one scenario that can halt an entire run before any order is submitted, and it is distinct from a per-order rejection. On any run that places orders, a sanity check runs against the calculated order set before anything is sent to the broker. If the total calculated trades look implausible relative to the managed value you defined for that connection, the run halts. No order in that run is submitted.

This is a pre-execution check, not a response to a broker rejection. It fires before the broker sees anything, and if it fires, the run stops entirely rather than partially. The halt is recorded in the audit log with a reason, so you can identify that a particular scheduled run did not execute and understand why.

The check exists to address a narrow class of problem: a calculation error or a stale position read that could produce an order set wildly out of proportion to the account value. A portfolio in a normal state produces a small corrective order set on each rebalance date. An order set that looks structurally wrong relative to the managed value is stopped rather than executed. This is not the same as an order rejection: a rejection happens at the broker, after submission, and affects one position. The sanity check happens before submission and affects the whole run. The two events have different causes, different records, and different remedies.

Pre-defined rules of this kind are what supervisors look for in automated tools. In its review of digital advice tools, FINRA lists among effective practices for automatic rebalancing "developing policies and procedures that define how the tool will act in the event of a major market movement" (FINRA, Report on Digital Investment Advice, 2016). A halt that fires before submission, and records why, is one concrete version of that idea.

Three outcomes that can look alike in the log

Outcome	When it happens	What it affects	What happens next
Broker rejection	After submission, at the broker	One order; the rest of the run continues	Recorded with the broker's reason; retried only through the next scheduled run
Sanity-check halt	Before submission, on any order-placing run	The whole run; no order is sent	Recorded with a reason; the next scheduled run starts fresh
Zero-trade run	When the portfolio has not drifted meaningfully	Nothing; there is no gap to close	Nothing to fix; this is the expected outcome

What a run with no trades is not

One scenario is worth distinguishing from a failure because it can look similar in the audit log: a scheduled run that produces no orders because the portfolio has not drifted meaningfully from its target weights on that date. The construction process runs, finds no gap worth closing, and produces nothing to submit. That is the correct outcome. The run fired; it did its job; the portfolio did not need correcting on that date.

This is not a failure and it is not a rejected run. It is what a well-maintained portfolio looks like between significant market moves. The trigger article covers what the scheduler does when it fires and how the absence of drift produces a valid run with zero orders.

What the system does not do

Several behaviors are worth naming plainly because they represent the alternatives a connected investor might reasonably fear.

• It does not move on silently after a rejection without recording it. Every rejection goes into the audit log with the broker's stated reason.
• It does not abort the remaining orders when one position is rejected. The run continues with the positions it can correct.
• It does not hide partial completions. A run of twelve orders with two rejections produces ten fill records and two rejection records, not twelve success entries.
• It does not automatically retry rejected orders within the same run. A failed order is recorded and the next opportunity to attempt the correction is the next scheduled rebalance.
• It does not make additional trades to compensate for a failed one. The remaining orders close the gap on their own positions; they do not adjust for the missing correction on the failed position.

How to review a run and what to look for

If you want to understand what happened in a specific rebalance, the execution history for your connection is where the record lives. The information available is what the broker reported: which orders filled, which were rejected, and the reason given for each rejection.

If a rejection was transient, such as an instrument that was briefly unavailable, the same position will be included in the next scheduled rebalance calculation and the correction will be attempted then. If a rejection was structural, such as a delisted instrument, that position may need attention before the next run can address its drift.

If you want to look into a recurring rejection without new orders going out in the meantime, switching to Manual mode keeps tracking drift while Acubic places nothing.

Both broker connection guides describe the failure recording behavior as it applies to each broker. The eToro connection article and the Trading 212 connection article document the same principle on each side: the rejection is attributed to the position, the broker's stated reason is preserved, and the remaining orders in the run are unaffected. The behavior is consistent; the only difference is the broker the rejection comes from.

If you are trying to understand the full audit picture across all runs, rather than a single rejected order, the automation modes article covers what the audit log records and the properties that are constant across all three modes. The methodology page documents the construction process that generates the order set in the first place, including the five published model limitations, for readers who want to understand the inputs before thinking about what can go wrong in the execution.

Acubic does not promise returns and does not predict short-term market moves. When a broker rejects part of an order set, the record is there, the rest of the run stands, and the remaining gap waits for the next scheduled date. That is the full behavior, stated as precisely as it is documented.

Sources

1. Trading Suspensions, U.S. Securities and Exchange Commission, 2026, accessed 12 October 2026.
2. Holidays and Trading Hours, New York Stock Exchange, 2026, accessed 12 October 2026.
3. Report on Digital Investment Advice, FINRA, March 2016, accessed 12 October 2026.