Automated monitoring plateaued years ago. The next curve hasn't started.
Ask anyone selling AI into compliance functions where the industry sits on the adoption curve, and most will describe one line rising from zero. It is not one line, and it does not start at zero.
Adoption does not move in a straight line. Something new arrives and for a long time almost nobody uses it — not because it does not work, but because the practice around it has not been built yet. Then it turns, and climbs quickly, because the obstacles have gone and using it has become the ordinary thing to do. Then it levels off, not because anyone lost interest but because everything that could sensibly be moved onto it already has. Drawn out over time, that line looks like a stretched S, which is where the name comes from.
The flat stretch at the top is the part that matters here. From inside a firm it looks identical to a finished job.
The first curve, and where it stopped
The automated compliance engine at the centre of a buy-side operation has been on its own adoption curve for the better part of two decades. It began with monitoring done entirely by a person against a paper mandate, moved through spreadsheets that automated the arithmetic but not the checking, then a reporting layer that surfaced breaches after the fact rather than a person reading a trade blotter. The next step put the checks on the engine itself, post-trade. The most recent step, and the one most firms are still working through, moved monitoring pre-trade: the engine tests an order before it executes and blocks what breaches a coded rule.
That is the top of the curve most asset managers are already standing on, and it has been the top for years. Coding a new restriction class or tuning a threshold barely moves the needle now, because the codeable rules were coded long ago and what is left in that category is a marginal gain on an already-automated process. I have spent most of two decades on that layer, and the return on each release diminished long before a model was involved.
Why the second curve starts from the top of the first
A new curve is beginning, and it does not start underneath the first one. It starts roughly where the first curve levelled off, because it inherits the exception-handling infrastructure and the habit of a person confirming before anything is recorded as a decision. What it does not inherit is a coded rule set, because the work on this curve was never coded to begin with: guideline documentation, register maintenance, and the checks that live in a spreadsheet because nobody built a rule for a one-off side letter term.
Early on, this curve looks unimpressive, and most vendor pitches skip past that part. AI-assisted systems doing this work today prepare and flag; a person still reads every output before it becomes a record. The gain at this stage is real but modest, and anyone promising more than that is describing a demonstration rather than a production process.
It steepens from here for a reason that has little to do with model quality improving further, though it has. It steepens because the work sitting underneath it is larger than anything the first curve ever touched. Most of a compliance team’s week, by most accounts I have seen across different firms, sits in exactly this category, and until recently no tooling was capable of touching it responsibly.
What caps this curve is not technical
The first curve was capped by what could be coded. Some restrictions are genuinely computable and the rest stayed manual no matter how good the engine got. The second curve is capped by something else. Its ceiling is not full automation of monitoring. It is AI-assisted monitoring, pre-trade and post-trade both, with a named person still confirming every output that carries regulatory consequence. That ceiling is not a current limitation waiting to be engineered away — it is where the curve is meant to stop, because a monitoring decision without a human sign-off is not a control, however accurate the model behind it is.
Where firms conflate the two curves
The mistake I see most often is measuring the second curve against the first curve’s yardstick. The first curve produced a number: rules coded, or a share of the monitoring universe moved pre-trade. The second curve does not produce a comparable number, and asking it to invites the kind of unsupported claim this audience is right to distrust. What it produces instead is capacity in a team that has been one person short for months, and a record of the checks that found nothing, which is the evidence an auditor actually asks for.
The other mistake is assuming a firm that finished the first curve has finished automating compliance. Pre-trade blocking on the engine says nothing about whether the guideline register is still accurate, or whether last quarter’s liquidity check has a signed record behind it. Those questions sit entirely on the second curve, and for most functions it has barely started climbing.
A practical starting point
Take one piece of monitoring work and place it honestly on one curve or the other. If it is coded on the engine, it sits on the first curve, and no amount of attention from an AI vendor will move it further — that ceiling was reached years ago. If it is a person reading a document or checking a spreadsheet, it sits on the second curve, and the useful question is not whether AI could touch it, but where the sign-off sits once it does.
The checks that sit on that second curve are covered on manual monitoring.
Ferenc Elekes is the founder of Dobosi Consulting, which builds auditable AI workflows for investment compliance functions. This is a personal view and not legal or regulatory advice.