The question in front of a compliance officer asked to approve automated routing is not whether the signals are any good. That is the investment committee's question and it is a different meeting. The question here is narrower and harder: when this system does the wrong thing at three in the morning, what stops it, how fast, and who is accountable for the interval before it stopped.
Approve it on the basis of expected behaviour and you have approved nothing. Every control below is about the unexpected case, because the expected case is the one nobody needed a control for.
What the screen actually commits you to
Look at the surface before writing the memo, because the scope of what you are approving is visible on it.
At capture the tabs read Signals, My Trades, Terminal, Accounts, Portfolio, Autopilot and Performance, with action buttons including a tour, alerts and Autopilot. The description panel said the feed is aggregated across momentum, relative strength, reversal and macro tilt engines along with manual desk entries, and that every row routes into the Universal Trading Engine. The hero copy added that signals are confidence scored and deduped across sources, one click into that engine.
Two things follow for the assessment. First, the population you are approving is the whole feed, not one engine, so the control set has to cope with every source that can write a row including manual desk entries. Second, "one click" is the manual path, and the approval question is what replaces that click.
I am not going to tell you which of the controls below the module enforces internally, because that is exactly the thing an assessment establishes with evidence rather than takes from an article. Walk each one with the vendor, get a demonstration rather than a description, and record for each control whether it is enforced in the product, enforced by you outside the product, or not enforced at all. That third column is the useful one.
The four controls, and where each has to live
Instrument whitelist first, and it must be a positive list. A blocklist fails the moment a new instrument appears, and new instruments appear constantly. Key the list on the venue and instrument pair rather than the symbol, because the same ticker at two venues is two different risks with two different settlement paths. Anything not on the list is refused by default, additions require named approval against stated criteria, and the list is reviewed on a schedule rather than when someone remembers.
This control does more work than it looks like it does. The platform describes coverage spanning crypto spot and perpetuals, equities, forex, commodities, metals and prediction market contracts. A mandate that permits none of those last categories needs the whitelist to be doing real enforcement rather than sitting in a policy document.
Notional caps second, and they need four dimensions: per order, per instrument, per interval, and per day, with gross and net stated separately. A single daily cap is trivially satisfied by a system that spends the entire allowance in ninety seconds.
The important design point on caps is defence in depth. A cap enforced only in the routing layer is a cap that fails in the same event that causes the incident, because a malfunctioning router is not going to reliably enforce its own limits. Push the hardest version of the cap as far down as you can control: sub-account segregation, and per-key limits at the venue where the venue supports them. Then the routing layer's cap is the first line rather than the only one.
Kill switch ownership third. Name a person and name a deputy, both reachable during every hour the system can trade, which for crypto means every hour. Give them the authority to stop the system without escalating first, and write into the policy that using it is never a career risk. A kill switch nobody will pull without permission is a kill switch with a latency measured in phone calls.
The switch also needs a path that does not depend on the platform being reachable. Revoking the execution credential at the venue is that path, and it should be documented, permissioned to the same named owners, and tested. If the only way to stop the system is a button inside the system, then the system's availability is a precondition for stopping it.
Credential handling fourth, and this one is not negotiable regardless of what the automation does. Execution keys are scoped to trading and reading only, with withdrawal permission never granted. Assets not required as trading collateral sit in custody separated from the routing venue. Keys rotate on any personnel change and on any suspicion of exposure, and they are never transmitted to anyone, internally or externally, for any reason including support requests. A key that can move assets converts every automation bug into a solvency event instead of a trading loss.
Proving the kill switch works rather than believing it does
Every firm I have seen with an untested kill switch believed it worked. Some of them were right.
Rehearse it, in production, on a scheduled date, with the named owner performing the action rather than an engineer standing in. Measure four things: the time from decision to activation, the time from activation to the last order actually reaching a venue, whether any in-flight orders completed after activation, and the state of positions afterwards.
That third measurement is the one that surprises people. Stopping new orders is easy. Orders already in flight are not recalled by anything, and if the automation had staged a schedule, some of it may execute after the switch. The answer is not that this must not happen. The answer is that the number is known and stated in the approval memo, so that when it happens the response is a documented expectation rather than an investigation.
Then answer the harder question the rehearsal raises: what is the intended state after the switch. Flat, frozen with positions retained, or hedged. Each is defensible and they are not the same, and the wrong time to decide is while the switch is being pulled. Write it down, and write down who may override it.
The daily attestation, and what makes it more than a signature
An attestation that says the system operated normally is worth nothing, because the person signing it has no way to know and everyone involved understands that. An attestation is only a control if it forces someone to look at something they would otherwise not look at.
Four items make it real. Positions reconciled to the venue's own record, not to the platform's display, with breaks listed individually. Orders sent against orders intended, so that anything the system did which nobody asked for is visible as a count. Every cap breach and every whitelist refusal from the previous day, including the ones that worked as designed, because a rising count of refusals is an early warning that the universe has drifted from the mandate. And any period where the system was running without monitoring.
Sign-off belongs to someone who could realistically have said no. If the attestation is signed by the person who built the automation, you have documentation rather than a control. And the exception path has to be defined in advance: what a break means, who is told, within what window, and what happens if the same break appears three days running.
What the dashboard numbers are, and are not, in an approval memo
The header tiles at capture read two active trades, zero opened today, an average win rate of 96.6 percent, and a best source of MRE described as highest thirty day performance.
Those are dashboard readings from one moment. They are not a validated track record, and the difference matters enormously in a document that will be read by someone assessing whether the firm exercised diligence. Before any performance figure enters an approval memo, establish what population it covers, whether it includes closed and open positions, whether it is computed on realised outcomes or marks, how it treats partially filled or dropped signals, and over what window. If those answers are not available with evidence, the figure does not go in the memo at all.
An approval that leans on a headline number is an approval that becomes indefensible the moment the number is questioned, and it will be questioned at precisely the worst time. An approval that leans on a whitelist, layered caps, a rehearsed kill switch with a measured activation time, and a daily attestation with named exceptions is defensible whatever the returns did, which is the only kind of approval worth signing.