What Human-in-the-Loop Means in Fraud and AML

Last updated: September 2026

Every vendor selling automation into a financial crime function will tell you there is a human in the loop. None of them is lying. The phrase has simply been asked to carry so much that it no longer tells you the one thing you need to know, which is who is allowed to do what.

The short answer: human-in-the-loop is not a setting you switch on. It is a per-decision allocation of distinct rights — who may recommend, who may approve, who may close, who may escalate, who may file — and you should be able to say which role holds each one, on which decision type, before an agent touches a live queue.

TL;DR

• Human-in-the-loop means no action happens without a person. Human-on-the-loop means the system acts and a person supervises, sampling rather than confirming every case.

• The label a vendor uses tells you almost nothing. Both describe a spectrum, and neither specifies a position on it.

• "A human" is not one role. Recommend, approve, close, escalate and file are five separable rights, and regulated institutions already split them between different people.

• Depth of review should track the risk tier of the decision, not a platform-wide setting. The same institution will reasonably want full review on enhanced due diligence and a faster routine tier.

• A confirmation only means something if the person confirming could have reached a different conclusion — which sets a floor for what has to be on screen at the moment of decision.

• There is no supervisory rulebook for this. The revised model risk guidance issued in April 2026 puts agentic AI explicitly outside its own scope, so the position has to be decided internally, written down and defended.

• In-the-loop and on-the-loop are not alternatives. They are consecutive stages, and evidence is what earns the move between them.

Why "human in the loop" stopped telling you anything

The claim is unfalsifiable as usually stated. A system where an analyst clicks confirm on four hundred recommendations a shift has a human in the loop. So does a system where two control officers must independently agree before a customer's risk rating moves. Those are not the same operating model, and the phrase does not distinguish them.

Practitioners have noticed. Some of the liveliest discussion of the term sits in forum threads arguing that the human in the loop is a story we tell ourselves — which is an unusual thing to find under a definitional question, and a fair signal that the published answers are not satisfying anyone.

The question underneath does have an answer. On this queue, at this confidence level: who may recommend a disposition, who may approve it, who may close the alert, who may escalate it, and who may file. Those are five different rights, and they are not always held by the same person.

One scoping note, so nobody reads the wrong piece. This is about how review works inside a single decision. Whether fraud and AML should sit on one platform, and what each function retains when they do, is a separate argument with a separate answer.

What human-in-the-loop and human-on-the-loop actually mean

Human-in-the-loop means the system produces a recommendation and a person acts on it. No action reaches the customer, the case or the report without someone deciding. The system's output is an input to a human decision, never a substitute for one. The phrase comes from machine learning, where human-in-the-loop originally described people labelling training data and correcting model output; in a risk context it has moved from labelling to deciding.

Human-on-the-loop means the system acts and a person supervises. Work completes without individual sign-off, and the human reviews samples, monitors aggregate behaviour and intervenes when something looks wrong. Oversight is real but retrospective, and it covers a population rather than a case.

There is a third arrangement the pair leaves out, and in regulated work it is the one that matters most: the system declining to act and routing to a person on purpose. More on that below, because it behaves differently from either label.

The differences that matter, and the one that does not

Two of those rows do the real work. Whether the absence of a person blocks the action is the architectural difference. Whether the record shows a decision or a confirmation is the governance difference, and it is the one an examiner will ask about.

The difference that does not matter is which label the vendor uses. Both terms describe a spectrum rather than a position on it, so "we're human-in-the-loop" and "we're human-on-the-loop" are equally compatible with almost any arrangement you could actually build.

Here is the pivot. No institution deploys one of these — it ends up with different answers on different queues, and frequently different answers on the same queue at different confidence levels.

So there is no such thing as a human-in-the-loop agent in the abstract. Review depth is best modelled as a per-agent attribute, with values along the lines of analyst reviews output, fully automated, or configurable, and that third value is the honest one. Which means the useful artifact is not a label but a map.

The five rights a human can hold over an agent's decision

Decompose the phrase and it stops being vague. On any fraud or AML decision there are five distinct rights, and each can sit with a different role.

Recommend. Propose a disposition, with the reasoning behind it. The holder needs access to the case and the evidence. This is the right an agent can hold, and the only one it should.

Approve. Accept the recommendation and make it the institution's position. The holder needs enough in front of them to disagree — see the next section, because this is where most review models are actually weak.

Close. End the matter and update the record. Closing is not the same as approving: an approved disposition that nobody closes is a case still open, and a closure without an approval is an audit finding.

Escalate. Route the case up or across — to enhanced due diligence, to a control function, to a committee. The holder needs to know what escalation triggers exist and to be able to fire one without asking permission.

File. Submit a report to an authority. This is the most tightly held right in any BSA programme and the least negotiable.

These are not hypothetical splits. On a recorded call, a director of financial crimes compliance at a bank described who may override a customer risk rating at their institution: the right is limited to two control roles, the financial crimes lead and the BSA officer. Analysts do not override — they escalate the case to a queue to have the change confirmed, and it comes back for approval as a quality-control step. Recommend and approve are two rights, held by two different sets of people, in a process that existed before any agent arrived.

The split predates agents in the rulebook too. Role-based controls in a BSA programme already enforce that the analyst who prepares a suspicious activity report cannot be the person who submits it — the standard separation-of-duties requirement, and the same idea banking controls have long called the four eyes principle. Preparing and submitting were always different rights held by different people. The agent simply occupies one more seat in a chain that already had several.

This is also why the house position is stated narrowly rather than as a slogan. Oscilar's agents never autonomously close or escalate alerts — every recommendation is reviewed and confirmed by a human analyst before any action is taken. That is a more useful commitment than "human-in-the-loop", because it names the rights the agent does not get.

One right this piece deliberately does not settle: when fraud and AML share a platform, which function owns the filing decision. That is an organisational accountability question rather than a per-decision one, and it deserves its own treatment.

Which queues get which setting, and why depth tracks risk

Stated the way a practitioner would state it, the configuration question is this: for which alert types is a high-confidence false-positive recommendation enough for a one-click clear, and for which should the agent always flag for review regardless of confidence?

That question has different answers across a book of work. Low-value retail fraud with a very high confidence score is a candidate for rapid confirmation. Anything involving account takeover or a high-dollar amount should get active review of the reasoning whatever the confidence says. A routine periodic risk rating is not the same decision as enhanced due diligence, and should not inherit the same review depth.

The organising principle is easier to hear from a practitioner than from a vendor. A risk leader at a fintech, describing their own programme on a recorded call, said they are heavily human-in-the-loop on every risk rating and think that is right for enhanced due diligence, for high-risk customers and for industries that require it — and in the same breath said they would like the time spent on the routine tier to come down. One institution, two positions, one system. Nothing about that is inconsistent.

So the answer is not a platform-level setting. It is risk appetite and standard operating procedure expressed per queue, and you should expect to write it down rather than inherit it from a product. The agents that work these queues can be configured either way; the thresholds are yours.

The natural place for that writing-down is the setup of a proof of concept, where thresholds get defined against real queues before anything runs unsupervised. What those thresholds should look like, and what acceptance criteria to hold a pilot to, is a separate piece of work worth doing properly.

What a reviewer has to see to own the result

A confirmation is only worth something if the person confirming could have reached a different conclusion. That is the whole test, and it sets a minimum for what must be in front of them at the moment of decision: the input, the reasoning, the evidence, the typologies considered, and a confidence level.

The regulator's version of this test is sharper than most vendors', and it survived the 2026 rewrite of the model risk guidance intact. Effective challenge, the guidance says, is performed by individuals with the appropriate expertise to conduct a critical and objective challenge, sufficient independence to maintain objectivity, and — the condition people forget — "the organizational standing and influence to effect any change." A reviewer who cannot change the outcome fails the third condition. They are not performing review.

That reframes what an audit trail is for. Its most useful property is not that it records what the agent did. It is that it makes it straightforward to show, case by case, where humans made the decisions. A trail that captures the agent's reasoning, the evidence and the typologies behind each recommendation, alongside every action taken by an agent or an analyst with reasoning and timestamps, is a record of the human layer rather than a record of the machine.

Completeness matters as much as depth. Agents run against every item entering a configured queue rather than a sample, so there is no population being silently skipped — which is a different claim from "we reviewed a lot of alerts" and a much easier one to evidence.

What that trail must retain, who may configure it, and who approves a change to the model behind it are control-framework questions rather than review questions. They are covered in AI agent governance for risk teams.

When the agent declines to decide

Sometimes the right output is not a disposition. When key attributes are missing — a date of birth, an address, a confirmed nationality — the correct behaviour is to flag the specific gaps and recommend manual review rather than force a call. Auto-dismissing a case on thin corroborating evidence is the cheapest way to increase regulatory risk.

The workflow that follows is straightforward. The agent runs first and names what is missing. A request for information goes out. The agent reruns once the data comes back, and can usually produce a higher-confidence recommendation than it could the first time.

There is a consequence for what you should expect from a pilot. An automation rate reflects data completeness as much as model quality, so a disappointing rate can be a data problem wearing an AI costume. Before concluding that the agent underperformed, check what proportion of its cases it declined for missing attributes.

This is a third position on the spectrum, and it is the one a regulated institution should want most often. More human involvement here is the system working, not failing.

There is no supervisory rulebook for this yet

This is the part that explains why every vendor can claim a human in the loop without contradicting each other.

On 17 April 2026 the federal banking agencies issued revised guidance on model risk management — SR 26-2 at the Federal Reserve, Bulletin 2026-13 at the OCC, and FIL-15-2026 at the FDIC. It supersedes the 2011 guidance that the industry knew as SR 11-7, and it also supersedes the 2021 interagency statement on model risk management for systems supporting Bank Secrecy Act and anti-money laundering compliance. If your model risk policy cites either of those, it cites a rescinded document.

The revised guidance then declines the question this piece is about. "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance," the OCC bulletin states, and SR 26-2 confirms that its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI. The agencies say they plan to issue a request for information covering banks' use of AI, and it has not been issued.

Be precise about what that does and does not mean. The model risk framework does not currently reach the agent. The underlying obligations on the decision itself have not moved at all — the reporting duty, the recordkeeping, the expectation that a decision has a named owner and a defensible basis are exactly where they were. What is absent is a supervisory answer to how much human involvement an agent decision requires.

Which is the whole point of this page. You cannot look the answer up. The position has to be decided internally, written down, and defended — per queue, per decision type, per right.

One note on applicability, because it is easy to over-read. The revised guidance states that it is expected to be most relevant to banking organisations with over $30 billion in total assets. "Most relevant to" is not "applies only to", and plenty of institutions below that line will still be asked by an examiner how their agent decisions are governed.

From confirming everything to sampling: what earns the shift

The two arrangements are not a choice you make at purchase. They are consecutive stages, and treating them as alternatives is the most common mistake in this whole conversation.

The path, as it actually runs, has three steps. Run the agent at full coverage with an analyst reviewing every recommendation for an initial monitoring period. Use the reasoning trail to validate the agent's judgment against known outcomes and confirm it behaves as expected. Then shift from reviewing every case to periodic sample quality control, which is how second-line assurance already works for everything else.

What earns the move is evidence, not a calendar. There is no fixed timeline for it — the pace is set by each institution's own validation and comfort — and the audit trail and the explainability are what make the shift defensible to an examiner when it happens. Where a duration is unavoidable, the honest framing is weeks, not months, and anything more precise than that is invented.

It helps to know what the validating evidence looks like when it arrives. A bank in deployment shows 92% agent agreement with its analyst team on alert disposition, and 75% less time per review. Read that as an existence proof of the measurement rather than a number to expect: it is one deployment, and an agreement rate is the right shape for this question because it measures whether the human layer is changing outcomes or confirming them.

So in-the-loop and on-the-loop are where you start and where you may earn the right to get to. Not a decision made once, in a procurement document.

Where this breaks

Four failure modes, and one that nobody has solved.

Review as theatre. A reviewer with a queue longer than the shift confirms rather than decides. This fails the effective-challenge test while satisfying every dashboard, because the dashboard counts confirmations and cannot tell the difference. If your review rate is 100% and your disagreement rate is nearly zero, that is a finding, not an achievement.

Bottleneck at the wrong tier. Requiring full review on a queue that does not need it consumes exactly the attention the high-risk tier was supposed to get. Human-in-the-loop automation applied uniformly is not conservative. It moves the risk somewhere less visible.

Rights assigned to the wrong role. If the person who may close an alert lacks the standing or the independence to reverse it, the control exists on paper only. This is the effective-challenge test applied to your own org chart, and it is worth actually doing.

Invisible corrections. When a human departs from the agent's recommendation and that departure is not surfaced to the next reviewer, two people reach different conclusions from the same record. Capturing and feeding back those departures is a distinct problem from allocating the rights, and it deserves its own treatment.

Then the unresolved one, stated as unresolved. The agent runs on infrastructure the institution may not own, and the review model has to work on top of whatever case management already exists. Agents can run as a standalone layer on top of infrastructure you already have, or as part of the unified platform — but either way the reviewer's screen, the audit trail and the escalation path have to reconcile with systems that were not designed for an agent's recommendation. If you are adding agents to an existing risk stack, that reconciliation is the work, not the integration.

Frequently asked questions

What is human in the loop?

Human-in-the-loop means a person makes or confirms the decision, and no action happens without them. The system produces a recommendation with its reasoning; the human evaluates it and decides. In a fraud or AML context that means an agent can propose a disposition but cannot close, escalate or file on its own.

What is the difference between human-in-the-loop and human-on-the-loop?

The blocking distinction: with a human in the loop, the absence of a person prevents the action, so work waits. With a human on the loop, the system acts within configured limits and a person supervises by sampling and intervening. The first produces a record of decisions with a named decider per case; the second produces a record of oversight across a population.

What does human-in-the-loop mean in fraud and AML specifically?

It means naming who holds each of five separate rights on a given decision: recommend a disposition, approve it, close the alert, escalate the case, and file a report to an authority. Those rights are routinely held by different roles, and an agent should only ever hold the first. A vendor who cannot tell you which role holds which right on which queue has not answered the question.

Who approves an automated fraud or AML decision?

It depends which right you mean, and that is the useful answer rather than an evasion. An analyst may be able to recommend a change to a customer risk rating while only a control role — a financial crimes lead or a BSA officer — may approve one. Approval, closure and filing are frequently three different people, and the approver needs enough of the reasoning and evidence in front of them to disagree.

Can an AI agent close an alert on its own?

Not in Oscilar's model. Agents never autonomously close or escalate alerts; every recommendation is reviewed and confirmed by a human analyst before any action is taken. Whether another system permits it is a question worth asking directly, because "human-in-the-loop" as a phrase does not rule it out.

Who files a suspicious activity report when an agent drafted the narrative?

The filing right stays with the role that holds the reporting obligation, and drafting assistance does not transfer it — role-based controls generally also prevent the person who prepared a report from being the one who submits it. Where fraud and AML share a platform, which function owns that filing decision is an organisational accountability question that deserves its own treatment. Confirm the specific requirements for your institution with your compliance counsel.

Does keeping a human in the loop slow decisioning down?

It moves the cost rather than removing it. Full review on every case spends human attention evenly, which is why a uniform setting tends to starve the high-risk tier while over-serving the routine one. The risk-tier map is how you decide where to spend it: heavy review where the consequence is serious, faster confirmation where a high-confidence recommendation on a low-value case is genuinely enough.

How is human review of an agent decision audited?

Through a trail that records the input, the agent's reasoning and evidence, the confidence level, and every subsequent action by an agent or an analyst with timestamps — so it is straightforward to show where a human made each decision. Because agents run against every item in a configured queue rather than a sample, there is no population silently excluded from that record. What the trail must retain and who may change it are control-framework questions, covered in the governance piece.

Can this work with an institution's existing risk systems?

Yes. Agents can run as a standalone layer on top of infrastructure you already have, or as part of the unified platform. The thing to scope carefully is not the integration but the reconciliation: the reviewer's screen, the audit trail and the escalation path all have to work with a case management system that predates the agent.

If you are working out where the review line should sit on your own queues, that conversation is more useful with a specific decision type in front of it than in the abstract. Talk to us about a one-week agent proof of concept on a single queue, with the review model defined before anything runs.