Trust Nothing on the Wire: A Callback-Challenge Protocol for Deepfake-Resistant Payment Authorization in Small Businesses

The proliferation of sophisticated deepfake technologies has rendered traditional identity verification methods vulnerable, making deepfake-enabled payment fraud an increasingly viable threat, particularly for small businesses (SMBs) that often lack the advanced detection capabilities of larger enterprises. This paper proposes a novel Callback-Challenge Protocol designed to establish a robust defense against such attacks. The protocol operates on the principle of "trust nothing on the wire," assuming that inbound identity, whether voice or video, can be convincingly forged. Under this protocol, payment instructions exceeding a predefined threshold remain unexecutable until they are explicitly confirmed over pre-registered, out-of-band communication channels. Verification involves a transaction-bound challenge, where exact details (amount, payee, destination, reference) must be verbally confirmed. This approach structurally decouples authorization from potentially compromised primary communication channels, offering a deterministic operational decision framework with minimal infrastructure requirements, thereby enhancing fraud prevention for vulnerable SMBs.

Deepfake Fraud, Payment Authorization, Out-of-Band Verification, Callback-Challenge Protocol, Small Business Security, Cybersecurity, Social Engineering, Fraud Prevention Protocols

The digital transformation of business operations has brought unprecedented efficiency but also exposed new vulnerabilities. Small and Medium-sized Businesses (SMBs), in particular, are increasingly targeted by sophisticated cyberattacks, often lacking the robust security infrastructure and dedicated personnel of larger corporations [1]. A rapidly emerging and particularly insidious threat is deepfake-enabled payment fraud. Advances in artificial intelligence (AI) have made it possible to generate highly convincing synthetic voice and video, capable of impersonating individuals with alarming accuracy [2]. Attackers leverage these deepfake capabilities to execute elaborate social engineering schemes, convincing employees to authorize fraudulent payments by impersonating executives, vendors, or trusted partners [3].

Traditional fraud detection systems, often reliant on behavioral analytics or anomaly detection, struggle against deepfakes because the impersonation can be so convincing that it bypasses human and automated identity checks on primary communication channels. The core problem is that the apparent authenticity of an inbound request (e.g., a phone call from the CEO, a video conference with a vendor) can no longer be trusted at face value. This vulnerability is exacerbated by the common business practice of processing urgent payment requests based solely on verbal or visual confirmation over a single channel.

This paper introduces the Callback-Challenge Protocol, a proactive and deterministic defense mechanism against deepfake-enabled payment fraud. Instead of relying on the increasingly fallible detection of forged identities, this protocol assumes that any inbound identity can be compromised. It mandates an out-of-band verification process for all high-risk payment authorizations, ensuring that critical transaction details are confirmed over a pre-registered, secure channel that is separate from the initial request. This approach aims to provide SMBs with a simple, yet highly effective, framework to prevent financial losses due to deepfake-driven social engineering, thereby bolstering their cybersecurity posture in an evolving threat landscape.

The effectiveness of the Callback-Challenge Protocol is predicated on a realistic and conservative threat model that acknowledges the current capabilities of deepfake technology and social engineering tactics. We assume the following:

• Convincing Synthetic Media: Attackers possess the capability to generate highly realistic synthetic voice and video that can convincingly impersonate authorized individuals (e.g., CEO, CFO, key vendor contacts). These deepfakes can bypass human perception and potentially some automated biometric authentication systems [4].
• Channel Spoofing: Attackers can spoof caller IDs, email addresses, and even video conference identities, making it appear as though the fraudulent request originates from a legitimate source or channel [5].
• Urgency and Authority Pressure: Attackers are adept at applying psychological pressure, leveraging urgency, authority, and fear to compel targets to bypass standard procedures. This is a common tactic in business email compromise (BEC) and vishing (voice phishing) attacks, which are increasingly augmented by deepfakes [6].
• Targeting SMBs: Small businesses are particularly vulnerable due to their typically leaner security budgets, fewer dedicated cybersecurity personnel, and less complex, often more trusting, internal communication protocols compared to large enterprises [1].

Given this threat model, the defensible boundary shifts from attempting to *detect* a deepfake (which is probabilistically difficult and computationally expensive for SMBs) to controlling pre-established, secure verification channels and enforcing strict protocol adherence. The protocol assumes that the primary communication channel (e.g., the phone call or video conference where the fraudulent request is made) is compromised, and therefore, an independent, secondary channel is required for validation.

The Callback-Challenge Protocol is designed to be simple, robust, and implementable with minimal specialized infrastructure. It focuses on establishing a deterministic verification process for high-risk payment authorizations.

3.1. Setup

Prior to any transaction, the small business must establish and maintain a secure registry of critical information:

• Registered Approvers: A list of individuals authorized to approve payments above a certain threshold, along with their verified contact information for out-of-band communication (e.g., personal mobile number, dedicated secure messaging app, secondary email address).
• Approved Channels: A whitelist of communication channels designated for out-of-band verification. These channels must be distinct from the primary communication channels typically used for initial requests and should ideally be resistant to spoofing (e.g., a pre-registered phone number for a callback, an encrypted messaging service).
• Payment Thresholds: Clearly defined monetary thresholds above which the Callback-Challenge Protocol is mandatory. This can vary by business and transaction type.
• Escalation Paths: Defined procedures for situations where an approver cannot be reached, a challenge fails, or suspicious activity is detected during the verification process.

This setup phase is crucial for establishing the trusted foundation upon which the protocol operates.

3.2. Instruction Receipt and Hold

When a payment instruction is received that exceeds the predefined threshold, the system (or the receiving employee) is instructed to hold the request, regardless of the apparent authenticity or urgency of the source. Even if the request appears to come from a known executive via a seemingly legitimate channel, the protocol dictates that it must be treated as a high-risk instruction requiring secondary verification. This step is critical in countering the psychological manipulation tactics employed by deepfake-enabled social engineering attacks.

3.3. Callback-Challenge Verification

The core of the protocol lies in the Callback-Challenge Verification step. The employee receiving the high-risk payment instruction initiates an outbound verification call or message to the registered approver using one of the pre-registered, approved out-of-band channels. Crucially, the employee does not use the contact information provided in the inbound request, but rather the independently verified contact information from the secure registry established in the Setup phase. During this outbound communication, the employee challenges the approver to confirm the exact transaction tuple: `amount + payee + destination + reference`. The approver must verbally confirm these specific details, demonstrating knowledge of the transaction that an impersonator on the primary channel would likely not possess or could not convincingly replicate across a separate, secure channel.

3.4. Escalation Rules

If any of the following conditions occur during the Callback-Challenge Verification, the payment instruction is immediately escalated and placed on a permanent hold:

• Unreachable Approver: The registered approver cannot be reached via the designated out-of-band channels within a reasonable timeframe.
• Tuple Mismatch: The approver fails to confirm the exact transaction tuple, or provides conflicting information.
• Bypass Pressure: The approver (or the impersonator) attempts to pressure the employee to bypass the verification protocol, citing urgency or authority. This is a strong indicator of a fraudulent attempt.

These escalation rules provide a clear, unambiguous framework for handling anomalies, ensuring that suspicious requests are never processed without full, verified authorization.

Traditional cybersecurity approaches to fraud often focus on detection: identifying malicious activity through signatures, behavioral anomalies, or AI-driven pattern recognition. While valuable, detection remains inherently probabilistic and adversarially brittle, especially against rapidly evolving threats like deepfakes. For SMBs, implementing and maintaining enterprise-grade deepfake detection stacks is often economically unfeasible and technically complex [7].

• Probabilistic vs. Deterministic: Deepfake detection is a probabilistic challenge; there will always be a false positive/negative rate. A protocol, however, offers a deterministic operational decision: if the challenge is met, proceed; if not, halt. This provides clarity and reduces cognitive load on employees.
• Adversarial Brittleness: Attackers continuously adapt their methods to bypass detection systems. A protocol, by shifting the trust boundary to pre-established out-of-band channels, creates a more resilient defense that is harder for attackers to circumvent without compromising the secondary channel itself, which is a significantly higher bar.
• Low Infrastructure Requirements: The Callback-Challenge Protocol requires minimal specialized infrastructure—primarily a secure registry of contact information and a commitment to process adherence. This makes it highly accessible and cost-effective for SMBs, unlike complex AI-driven detection systems.

By focusing on protocol verification rather than probabilistic detection, the Callback-Challenge Protocol yields deterministic operational decisions with low infrastructure requirements, making it a practical and effective solution for small businesses.

To assess the efficacy and practical implications of the Callback-Challenge Protocol, a multi-faceted evaluation plan is proposed:

• Longitudinal SMB Pilot with Simulated Social-Engineering Scenarios: Conduct a pilot program with a cohort of small businesses. This will involve periodic, controlled social-engineering simulations (e.g., simulated deepfake vishing attempts) to test employee adherence to the protocol under realistic pressure. The simulations will be designed to mimic current deepfake fraud tactics.
• Measurement of Adherence Under Urgency Pressure: During the pilot, specific metrics will be collected on employee adherence rates to the protocol, particularly when faced with simulated urgent or high-authority requests. This will help identify training gaps and areas for process refinement.
• Operational Overhead and Exception-Rate Tracking: Quantify the operational overhead introduced by the protocol (e.g., average time taken for verification, number of legitimate transactions delayed). Track the exception rate (e.g., instances where approvers are unreachable, or tuple mismatches occur for legitimate reasons) to refine thresholds and escalation paths.
• Qualitative Feedback from Employees and Approvers: Gather feedback from employees and approvers on the usability, perceived security benefits, and any friction points of the protocol. This qualitative data will be crucial for iterative improvements.

While the Callback-Challenge Protocol offers a robust defense, it is important to acknowledge its inherent limitations:

• Introduces Process Friction for Urgent Legitimate Transfers: The protocol, by design, introduces an additional step and potential delay for all high-value transactions. While necessary for security, this can create friction for legitimate urgent transfers, requiring careful communication and training to manage expectations.
• Requires Strong Channel-Registry Lifecycle Management: The security of the protocol heavily relies on the integrity and currency of the pre-registered out-of-band channels and approver contact information. Poor lifecycle management (e.g., outdated phone numbers, unrevoked access for former employees) can create new vulnerabilities.
• Scope is Payment Authorization, Not All Deepfake Abuse Classes: The protocol is specifically designed to prevent deepfake-enabled payment fraud. It does not address other forms of deepfake abuse, such as reputational damage, disinformation campaigns, or identity theft for purposes other than payment authorization.
• Human Element Remains Critical: While the protocol provides a clear framework, its ultimate success depends on human adherence. Employee training, awareness, and vigilance against social engineering tactics remain paramount.

1. 1.

   Sagiss. (2026, June 8). AI Phishing Statistics 2026: How AI Is Changing Cyberattacks on SMBs. Retrieved from sagiss.com

2. 2.

   Pindrop. (2025, June 12). Pindrop’s 2025 Voice Intelligence & Security Report Reveals 1,300% Surge in Deepfake Fraud. Retrieved from prnewswire.com

3. 3.

   StationX. (n.d.). Deepfake Statistics [2026]: Growth, Fraud & Detection Data. Retrieved from app.stationx.net

4. 4.

   DeepfakeDetector.ai. (2026, June 12). Deepfake Statistics 2026: 30+ Key Facts and Trends. Retrieved from deepfakedetector.ai

5. 5.

   Adaptive Security. (2026, April 15). Spear Phishing in 2026: Detection, Training & Prevention. Retrieved from adaptivesecurity.com

6. 6.

   ThreatScene. (n.d.). Social Engineering 2026: Why Most Breaches Still Start. Retrieved from threatscene.com

7. 7.

   Senzing. (n.d.). What Is Entity Resolution? How It Works & Why It Matters. Retrieved from senzing.com

8. 8.

   OneSpan. (n.d.). What is Out-of-Band Authentication? Retrieved from onespan.com

9. 9.

   Fraud.com. (n.d.). Out-Of-Band Authentication - Preventing identity fraud. Retrieved from fraud.com

10. 10.

    Cybersecurity.asee.io. (n.d.). Out of Band Authentication: Use Cases For Online Payments. Retrieved from cybersecurity.asee.io

11. 11.

    FedPaymentsImprovement. (n.d.). BRIEF #1: - Remote Authentication Landscape and. Retrieved from fedpaymentsimprovement.org

12. 12.

    ResearchGate. (n.d.). The Perfect Scam. Retrieved from researchgate.net