Written by Pete Eckermann

Executive Summary

• The problem with a reactive approach to scam operations is that only the symptoms are addressed and not the underlying illness or the underlying cause.

• Scams are at their core, a profitable business model – propagating across every digital communication channel (sms, email, voice call etc) and they are cheap to replicate and adapt.

• The friction from inter-organisational communication between banks, telcos and regulators means they can only react after the fact.  

• ScamStrike proactively engages scammers targeting banking customers the moment the campaign is surfaced, giving our partners the tools to erode scammer infrastructure and disrupt the business model of scam.  

‍

The problem with reactive scam defence

Scam defence is largely defined as a detection and response problem, which is only one part of the picture.  

In many cases, it is arguably the least insightful part about a scam in motion. If the only thing we do is wait for a signal, react to an alert, or clean up the damage after the fact, then we are not really addressing the root cause, and simply just responding to the symptoms.

Detection tells fraud leaders what has already happened. It does not tell you how the campaign was built, how it was executed, or what made it convert. It gives you no visibility into the genesis of the operation and it gives you no real tool for disrupting the next one. On top of that, tactics used by scammers evolve and show up differently in each stage of the scam lifecycle.  

Telcos see routing metadata. Banks see payment flows. Platforms see the lure. Each sees one layer of the operation, after it has already passed through. Apate sees the scam itself, from inside the conversation, while it is still in motion.   

‍

Scams are a business model, built to stay.

Modern scam operations are industrialised. They run acquisition, persuasion, conversion, and laundering stages across coordinated infrastructure. They use scripts, timing, and repetition. When one channel gets blocked, they shift to another. When one number gets flagged, they roll to the next. We routinely observe an operation hop between channels mid-campaign to stay ahead of detection.  

This lends to the underlying issue: the business model. Scams do not need to succeed every time. They need to remain cheap enough to run and profitable enough to repeat. That is why traditional fraud defence ends up in a loop. Blocking a payment disrupts one transaction. Filtering a call stops one attempt. Neither changes the cost structure of the operation generating those transactions and calls in the first place.

The most important thing to understand about modern scams is that they are not isolated criminal acts scams work as systems precisely because the teams defending against them are disconnected from one another.

That disconnection is not incidental. It is structural, and scammers rely on it. Each organisation responds to its own slice of the scam lifecycle without any of them being able to touch the campaign as a whole.

‍

Why the reactive model is outpaced

From a practical perspective, fraud defence teams are working through huge volumes of alerts under fixed protocols, responding to scams where every alert must be evaluated, every false positive costs time, and every escalation adds delay – resulting in increased losses, greater risk and loss of customer trust.  

One Tier-1 bank deals with over 50,000 transaction-rule flags a day, and every minute spent sorting the queue is a minute not spent actively understanding or disrupting the scam network behind it. The triage continues to happen, but it is difficult to treat the disease itself.  

The challenge is that the traditional response model is tuned to review what has already happened.   What it cannot produce is visibility into the campaign behind those attempts, what is driving it, how it is adapting, and where it is likely to go next.

‍

Why we built ScamStrike

We built Apate on the premise that the only way to meaningfully reduce scams is to erode the business model that makes them profitable. ScamStrike is the product expression of that premise for banking.

The core design decision was about timing. ScamStrike moves the point of engagement from after the customer has been contacted to the moment the scam number is surfaced. The moment Apate identifies an active scam number, our agents engage that infrastructure directly.  

The scammer’s business model depends on speed, repetition, and scale. The more time these scammers spend on a decoy interaction with Apate’s agents through ScamStrike, the fewer real victims that can be reached and the more actionable intelligence can be extracted and used by banks to disrupt future impersonation campaigns.

Traditional scam defence is a fortified position. Defenders build the wall higher every time they find a new way through. ScamStrike is a different doctrine. You go after their supply lines. Increase their operating costs, degrade their infrastructure, erode the capital flows that keep the campaign running. Starve the operation, and the attacks slow down on their own.

Across our deployments, we have seen scammer infrastructure abandoned, campaigns wound back mid-operation, and fraud teams generating intelligence from inside active scams rather than after the fact.

This has fundamentally changed what fraud teams are being asked to do. From defensive analysis to offensive capability, from reviewing what got through to actively breaking campaigns while they are still running.

‍

ScamStrike in Practice

For Apate’s work with one of the tier-1 banks, implementing ScamStrike was about testing a new operating model for scam prevention.

For fraud operations teams, ScamStrike does not replace existing detection and response workflows. It adds an upstream layer that changes the intelligence available to those workflows.

When your agents are engaging scam infrastructure directly, you are no longer working from the artefacts left behind after a scam completes. You are generating intelligence from inside an active campaign: how the operation is structured, what scripts it is using, what infrastructure it relies on, and how it adapts under pressure.

That shifts the operating model. The fraud team is no longer positioned entirely downstream of the scam, processing what arrived. They have visibility into what is running, and a mechanism to degrade it before it reaches customers.

‍

What has ultimately changed

Scam operations are becoming more capable of scaling without proportionally increasing cost or resources. They shift channels quickly, adapt scripts when one approach stops converting, and move infrastructure when it gets flagged. A purely reactive model will always be operating on a lag relative to that kind of adaptability.

Active disruption changes the timing advantage. Getting upstream of the campaign, rather than downstream of its outputs, means fraud teams can affect the operation while it is still running rather than after it has already caused harm.

ScamStrike is one part of a broader capability Apate is building across the fraud lifecycle. But the principle behind it applies regardless of the specific tool: the goal is not to count what the scam has already done. It is to make the scam financially unviable to run in the first place.

This was a problem that had no solution. The Apate team built one. What we have created is a genuinely paradigm shifting capability, one that for the first time gives the industry the tools to dismantle the business model of scam itself. I could not be prouder of the team that made that possible.