When we first started explaining the AVIEL architecture to fraud ops professionals, the most common initial response was "oh, so it's a honeypot." It's a reasonable first inference — honeypots are a well-established concept in security, and "honeybot" sounds like a portmanteau of honeypot and bot. But the architectural and operational distinction between the two is fundamental, not superficial. Understanding it matters for evaluating whether either approach is useful for APP fraud specifically.
What a Honeypot Does
A honeypot in its original cybersecurity sense is a decoy asset — a server, a network segment, a set of credentials — that has no legitimate production use and therefore any interaction with it is by definition suspicious. Honeypots work through passivity. They sit and wait. An attacker probing a network, scanning for vulnerabilities, or attempting credential stuffing eventually touches the honeypot. The honeypot logs that interaction and generates an alert. The attacker, assuming they aren't honeypot-aware, doesn't know the asset was fake.
Honeypots are highly effective in their design context: detecting network intrusion, scanning activity, and credential attacks. They require no active deception on the honeypot's part. The attacker brings the attack to the decoy. The decoy records it.
For financial fraud, honeypot-style bank accounts — sometimes called "canary accounts" — have been used by some institutions to detect account enumeration attacks: automated scanners that test whether account numbers are valid. A canary account number that receives an enumeration probe triggers an alert. Again, passive. The attack comes to the decoy.
Why Honeypots Fail for APP Fraud
APP fraud doesn't work by attacking system infrastructure. The scammer doesn't scan for vulnerabilities. They don't probe accounts. They identify a human victim, build a relationship with them, and instruct them to make a payment. The payment system never sees anything unusual — the victim comes to the payment system voluntarily with a clean authenticated session.
A static decoy account in the payment system is invisible to this attack vector. The scammer never touches the PSP's infrastructure until a real victim's payment arrives. There is no opportunity for a passive trap to trigger, because the scammer's attack chain never probes the PSP's network. The attack happens entirely in the conversation layer — the messaging apps, phone calls, and social platforms where the social engineering occurs.
This is the structural mismatch: honeypots wait for attackers to come to them, operating in the infrastructure layer where the honeypot lives. APP scammers operate in the conversation layer, which is entirely outside the PSP's infrastructure. A honeypot sitting in the PSP's systems is in the wrong place to intercept a scam that happens on WhatsApp.
What a Honeybot Does Differently
A honeybot is an active conversational agent, not a passive decoy. Instead of waiting for the attacker to come to the infrastructure where the honeybot lives, the honeybot goes to the attacker — in the channel where the scammer is operating. It presents as a potential victim in the scammer's own attack environment: the social media platform, the investment promotion, the messaging thread.
This distinction matters for three reasons.
First, the location of operation: the honeybot operates in the conversation layer, which is where APP fraud actually happens. It is present in the channel before the payment instruction is issued, before the victim has been fully converted, before the scammer has provided their controlled account details to a real consumer.
Second, the information extracted: a honeypot that gets touched by a scanner collects an IP address, a timestamp, maybe a credential attempt. A honeybot that engages a scammer in conversation collects the sort code and account number the scammer is using, the name they're operating under, the platform they're using, the messaging style and cadence, and the exact pretext they're deploying. This is a scammer fingerprint — a behavioral and operational signature.
Third, the timing: a honeypot generates an alert after the attack reaches it. A honeybot generates intelligence before the attack reaches any real victim. The fingerprint extracted from a honeybot conversation can be matched against payment instructions to real consumers in near real-time — flagging a payment that has a destination account matching a known scammer operation before the Faster Payment completes.
The Active vs Passive Distinction in Practice
We should be clear about what the "active" characteristic of a honeybot means and doesn't mean. A honeybot is not proactively hunting scammers across all of the internet. It is deployed in response to intelligence — a reported investment scam operation on a specific platform, a cluster of payment fraud claims pointing to a specific account, a known impersonation campaign. When activated, it engages the scammer's outreach channel as a responsive participant.
We're not saying a honeybot is a catch-all for all fraud types. It is specifically designed for APP scams that involve a conversation phase — investment scams, impersonation scams, romance scams, invoice fraud. Purchase scams that happen within minutes of a fake listing going live are a different timing dynamic. The honeybot is most valuable for scam types where the social engineering phase runs for hours, days, or weeks before the payment instruction, because that duration is the operational window the honeybot occupies.
The Liveness Problem
One challenge specific to active conversational agents is what I'd call the liveness problem: a honeybot operating in a complex scam conversation needs to be credible enough to sustain the scammer's engagement through multiple exchanges. A scammer who suspects they're dealing with a bot or a police honeytrap will disengage — or worse, adapt their methods. Keeping a sophisticated social engineer engaged long enough to extract useful intelligence is not a trivial NLP challenge.
The honeybot architecture we've built handles this through contextual response generation — the bot's responses are calibrated to the specific scam type (investment, impersonation, romance) and the specific stage of the engagement (initial contact, trust building, payment instruction). It doesn't need to be perfect; it needs to be convincing enough to keep the scammer engaged until the payment-critical information (account details, contact identifiers) is extracted. At that point, operational objectives are met regardless of whether the conversation continues.
The failure modes are also asymmetric. If a honeypot gets detected by an attacker, the attacker knows the network has intrusion detection and may adapt their approach — that's a non-trivial defensive loss. If a honeybot gets detected by a scammer, the scammer wastes time on a non-victim and moves on. The honeybot still collected partial intelligence during the engagement. The downside is bounded.
Where Honeybot Intelligence Plugs into the Fraud Ops Stack
The honeybot output — scammer fingerprints including destination account details, phone numbers, and communication metadata — needs to connect to the PSP's payment screening infrastructure to generate real-time pre-transfer alerts. This integration is via API: the AVIEL platform maintains a ledger of known-bad account and phone number combinations, and the PSP's payment system queries it at the point of payment submission, supplementing whatever transaction monitoring rules are already in place.
This is additive to the existing stack, not a replacement for it. Transaction monitoring continues to do what it does well — detecting anomalous authenticated sessions, high-velocity transfers, account-age patterns. The honeybot fingerprint layer adds a dimension that transaction monitoring categorically cannot produce: intelligence from the conversation that preceded the payment. Together, they cover more of the APP fraud kill chain than either does alone.