What the Acubic Audit Log Shows

Key takeaways

• The audit log records every order Acubic submits to a broker: fills, rejections, and sanity-check halts, each with the broker's own stated reason.
• A broker rejection affects one position. The other orders in the same run continue. The rejection appears in the log alongside the fills from that run.
• The audit log is always on, regardless of automation mode. In Manual mode Acubic places no orders, so there are no order events to record.
• A run that produces no trades is a correct outcome, not a failure. It appears in the log without rejections and means the portfolio had not drifted enough to require correction.
• You can review the execution history for any past run inside your connection settings, including the broker's stated reason for any rejection.

Connecting a brokerage account to an automated portfolio tool means handing it the ability to place real orders on your behalf. The question that follows is not just what it will do, but how you will know what it actually did, especially for the runs you were not watching. That is what the audit log answers.

This article explains what Acubic's audit log records, what each kind of entry means, and how the log applies across different automation modes and brokers. All of it is drawn from the behaviour already documented in the broker connection guides and the automation modes article, so there are no claims here that go beyond what those pages state.

What the audit log is for

The audit log is the execution record for every order Acubic places through a connected broker. Its purpose is to make any rebalance run reconstructable after the fact: what was ordered, what the broker accepted, what the broker refused, and why.

A log that records only fills is not an audit log. It tells you what succeeded but conceals what failed, and a hidden failure is the failure most worth knowing about. Acubic records both: every order submitted and its outcome, whether that outcome was a fill or a rejection. The rejection is recorded with the broker's own stated reason, not with Acubic's interpretation of it.

The log is always on. Automation mode changes who triggers execution, not whether execution is recorded. In one-click approval mode, you approve a proposed order set before anything reaches the broker. What the log records is what happened when the orders were actually submitted: which ones filled, which the broker refused, and the reason given for each refusal. The approved proposal and the completed run may not be identical, and the audit log is what tells you the difference. In full-auto mode, where scheduled rebalances execute without a per-run approval step, the log is the only record of what occurred. That is the mode where it matters most.

The properties that stay constant across all three automation modes, including the audit log, are set out in the article on one-click vs full-auto rebalancing.

The four types of log entry

Four types of outcome appear in the audit log, and distinguishing them matters when you are reviewing a run.

A fill is an order the broker accepted and executed. It records the instrument, direction, quantity, and confirmation time. A fill is the expected outcome for a position with drift that the broker can act on.

A rejection is an order the broker refused. It records the same fields as a fill, plus the broker's stated reason. Rejections from a run appear in the log alongside the fills from the same run, so you can read the complete picture of what happened across every position in that rebalance. The detailed behaviour of rejections, including why a single rejection does not cancel the other orders in the run, is covered in the article on what happens when a rebalance fails.

A sanity-check halt is distinct from a per-order rejection. It fires before any order is sent to the broker, if the calculated trade set looks implausible relative to the managed value defined for that connection. When it fires, the whole run stops and nothing is submitted. The halt is recorded in the log with a reason. It is not a failure of a single order: it is a pre-submission check that stops the entire run. The next scheduled run starts fresh from live positions rather than retrying the halted state.

A zero-trade run is a scheduled run that produced no orders. The construction process ran, calculated the gap between live positions and the strategy's target weights, and found nothing meaningful to correct. That is the correct outcome for a portfolio that has not drifted since the last run. It appears in the log without rejections. Zero-trade runs are not failures and do not indicate a problem with the connection. The article on what triggers an Acubic rebalance explains how the construction process determines there is no gap to close.

How rejections appear in the log

When a broker refuses one order in a rebalance run, the remaining orders continue. A rejection is isolated to the position it affects: it does not stop the run, roll back orders that have already been submitted, or prevent later orders in the same run from being sent. A run of ten orders with two rejections produces ten log entries: eight fills and two rejections, each with the broker's stated reason.

The broker's stated reason is preserved verbatim in the log. The two most common categories of rejection are an instrument that became unavailable or suspended between Acubic's position read and the order submission, and an order that falls below the broker's minimum order size. Those reasons look different in the log, and distinguishing them tells you whether the cause is likely to resolve on its own or requires attention before the next run.

Market hours do not produce rejections in the normal sense. On both eToro and Trading 212, Full Automatic runs are timed to the US regular session. A run that comes due outside market hours on Trading 212 returns a markets-closed message and stays pending until you approve it again during the open session. On eToro, an approved one-click proposal submitted outside market hours is queued by eToro until the market opens, rather than rejected.

A rejected order is not retried within the same run. The drift on the uncorrected position remains until the next scheduled rebalance, at which point the construction process recalculates from live positions and will include that position in the new order set if the drift is still present. If you want to investigate a recurring rejection without new orders going out while you look into it, switching to Manual mode keeps drift tracking active while Acubic places nothing. The article on pausing rebalancing without disconnecting explains that option.

How automation mode shapes the log

The audit log captures the same information in one-click and full-auto modes. What differs is when you become aware of it.

In one-click approval mode, you review the proposed order set before anything goes to the broker. You approve or decline as a batch. If you approve and some orders are later rejected by the broker, those rejections appear in the audit log and you can review them after the run completes. If you leave a proposal without acting, no orders are sent and no rejections are possible. An unapproved one-click proposal is not a failure; it is the mode working as intended.

In full-auto mode, the scheduler prepares and submits the order set without a per-run approval step. You are not present at the moment of execution. Rejections appear in the audit log and are visible the next time you review the connection's execution history. Full-auto does not change how rejections are handled or recorded: one order executes at a time, position sizing rounds down rather than up, and the same isolation of per-order failures applies.

In Manual mode, Acubic places no orders. The mode is effectively read-only: Acubic shows your live positions alongside the strategy's target and lists the trades that would be needed, but submits none of them. Because no orders are placed, there are no order events to record in the audit log.

How the log applies per broker

The audit log works the same way regardless of which broker is connected: every order submitted, filled, or rejected is recorded with the broker's own stated reason. Both the eToro connection guide and the Trading 212 connection guide document this behaviour in identical terms. What differs is the broker architecture, which changes which automation modes are available and therefore which kinds of run appear in the log.

On a standard eToro connection, the only automation mode available is one-click approval. Full Automatic runs, which produce log entries without a per-run approval step, are available only through an eToro sub-account: a separately funded account inside eToro where Acubic places orders scaled to the amount that sub-account was funded with. On a standard eToro connection, no setting inside Acubic enables unattended rebalancing, so the log for a standard eToro connection will contain only the outcomes of manually approved one-click proposals.

On a Trading 212 connection, all three automation modes are available directly on the main Invest account, including full-auto. Full-auto run entries appear in the Trading 212 log without requiring a separate sub-account. The connection does not support CFD accounts; it works only for Invest and Stocks ISA account types.

Reading the execution history

The execution history for your connection shows every run in reverse chronological order. Inside each run you can see the outcome for each position: fill, rejection, or not submitted. For each rejection the broker's stated reason is available.

A useful sequence when reviewing any run is to check whether the run completed at all, whether it produced any orders, how many filled, and whether any were rejected and why. A transient reason, such as a brief instrument suspension, is likely to resolve by the next scheduled run without any action on your part. A structural reason, such as a delisted instrument or a persistent minimum-size issue, may need attention before the correction can be applied.

The execution history covers all past runs for the connection. You can compare across dates to see whether the portfolio has been rebalancing on each scheduled date, whether any position has generated repeated rejections across multiple runs, and whether runs have been producing meaningful order sets or consistently coming in with zero trades.

The audit log is the record of what the system did. The construction logic that decided what the system should do is documented on the methodology page, which covers the five published model limitations alongside the construction process. Together they give a complete picture: the intended allocation, and the execution record of every attempt to defend it.

Why the log matters

Any automated capital that runs on a schedule without continuous human oversight requires a record that can be reviewed afterwards. The audit log is that record. It does not require you to be present at the moment of execution to understand what occurred.

The alternative is a system that reports only its successes, which is not auditable in any meaningful sense. Acubic records rejections alongside fills, preserves the broker's stated reason rather than summarising or omitting it, and makes the history available for any past run. That is what makes the execution record reviewable rather than merely confirmatory.

Acubic does not promise returns and cannot predict short-term market moves. What it can do is execute a scheduled rebalance against a connected broker account and record precisely what it ordered, what the broker accepted, and what the broker refused. The audit log is where that record lives.