How can banks tell a coached payment from a normal customer transfer?

Why coached payments look different from ordinary transfers

A coached payment is usually not just a transaction, it is a transaction under external direction. That changes the rhythm of the session. Banks are looking for behaviour that is paced, corrected, or steered by someone else, rather than the customer’s normal transfer habit. The most useful signal is not a single unusual click, but a pattern across the whole interaction.

What separates the two is often tempo and control. A normal customer transfer tends to follow a familiar path, with predictable navigation, stable timing, and few reversals. A coached payment often shows hesitation, repeated checking, abrupt pauses, or the customer moving step by step in a way that suggests live instruction. Those cues matter because they show influence over the decision process, not just the payment outcome.

That is why session-level scoring is stronger than event-level scoring. One strange pause can be harmless, but a sequence of pauses, retries, reversals, and copycat navigation can reveal that the payment is being assembled under pressure. The bank is not trying to prove coercion from one signal alone, it is trying to distinguish a self-directed customer journey from an externally paced one.

What signals are most useful for detection

The best indicators are behavioural and temporal. Banks should look for unusually long dwell times before confirmation, rapid switches between screens, repeated edits to payee or amount fields, and sudden bursts of activity after a period of indecision. A coached transfer may also show the customer following a brittle sequence of actions that is inconsistent with their normal shortcut use or usual transfer route.

Context matters as much as the individual signals. A customer who normally completes a transfer quickly but suddenly pauses at each step, or who changes behaviour when asked to confirm details, may be showing signs of external prompting. Similarly, a transfer that is technically valid but unusually “scripted” can indicate that the customer is reading from instructions rather than acting from memory or routine.

Detection works best when the bank compares the current session with the customer’s baseline and the current session with itself over time. The goal is to identify disruption in the interaction pattern, not simply to label a high-value payment as suspicious. That distinction helps reduce false positives while still surfacing coached activity that would otherwise look ordinary at the final payment state.

How banks should separate coached behaviour from normal friction

Not every hesitation is a red flag. Customers pause because they are checking payee details, switching devices, handling poor connectivity, or dealing with a complex payment. The practical test is whether the friction is explainable by the transaction context, or whether the pattern looks externally paced and unusually dependent on step-by-step instruction.

Friction from a legitimate transfer is usually locally driven. The customer may slow down, but the underlying pattern remains coherent. Coached behaviour often shows a broken flow, where the person seems to wait for direction, loses momentum, then resumes in short bursts. That difference is important because banks need to distinguish operational inconvenience from behavioural compromise.

NIST Privacy Framework is useful here because a coached-payment detection model depends on using behavioural signals carefully and proportionately. Banks should treat the model as an assistive risk signal, not a sole decision engine, and ensure that interventions are explainable enough for customer operations and disputes handling.

Risk and Threat Considerations

Coached payments are risky because the customer appears to authorise the transfer while the decision process is being manipulated in real time. That makes them harder to stop with standard fraud rules, especially when the transaction itself is otherwise valid and the bank only sees ordinary payment fields. The danger is that the behavioural compromise happens before the payment is submitted, not after.

Failure mechanism: The attacker or coach exploits the customer’s attention, trust, or confusion to shape the session into a controlled sequence of steps, so the payment looks customer-led while actually being externally directed.

Impact: Funds can be transferred to a mule account or scam beneficiary with a much lower chance of immediate reversal, and repeated coached sessions can train models or staff to underweight the warning pattern as “normal” customer friction.

Practitioner Guidance

What to verify: Treat baseline deviation as the first test. Confirm whether the same customer usually completes transfers with the same tempo, device pattern, and navigation path before you treat hesitation or reversals as meaningful.

Decision rule: If the session shows multiple signs of external pacing, escalate before payment completion rather than after the transfer posts. If the behaviour is noisy but self-consistent, keep the response lighter and avoid overreacting to a single pause.

What good looks like: The bank can distinguish ordinary customer friction from patterned, instruction-like behaviour and can intervene early without blocking every complex transfer.

Practitioner takeaway: The strongest signal is not “odd activity,” it is a payment journey that stops looking self-directed and starts looking choreographed.

Related resources from NHI Mgmt Group

• How should banks detect APP fraud when the customer is the one authorizing the payment?
• How should banks modernize customer authentication without adding friction at login and payment time?
• What are the signs that a payment scam is using social engineering rather than a normal customer request?
• How should banks and FinTechs respond when open banking gives new entrants direct access to customer data and payment initiation?