Deepfake Payment Fraud: A 30-Day Review for Caribbean SMEs

Editorial review: 11 November 2026. Unsupported regional statistics and incident claims have been removed. The original publication date is retained.

In January 2024, Hong Kong police received a report of a fraud involving a fabricated video conference and losses of about HK$200 million. The Hong Kong government’s June 2024 account says the conference was pre-recorded, used the likeness of a UK-based chief financial officer and was followed by payment instructions through instant messaging. It was not an interactive live conversation with the impersonated executive.

That case shows why a convincing face on a screen cannot by itself authorise a payment. It does not establish how often the same method is used in the Caribbean. This article offers a payment-control review, not a regional incidence estimate or a guarantee against fraud.

Find your local business context

The country guides can help frame questions for your bank and local advisers:

For wider account and system controls, read the AI-enabled fraud cybersecurity guide.

A practice scenario: a supplier changes its bank account

The following example is fictional. It is not a reported incident in Barbados.

A Bridgetown logistics firm receives a message asking it to update a supplier’s bank details. It refers to a real shipment. A follow-up call sounds like the supplier’s finance director. The accountant prepares the change, but the payment procedure requires confirmation through the contact already held in the supplier record.

Use the scenario to test three decisions:

Where does the contact number come from? The suspicious message and its attachments must not supply the number used to verify themselves.
What must be confirmed? The reviewer checks the intended supplier, bank details, invoice and reason for the change. Recognising a voice is insufficient.
What happens when verification fails? The payee change stays on hold. A deadline or a request for secrecy does not remove the approval requirement.

The example does not need an invented loss figure or an estimate of the attacker’s budget to be useful. Record where your own process would permit an unverified instruction to become effective.

Separate evidence from assumptions about the region

The FBI’s generative-AI fraud advisory describes voice and video impersonation. It does not provide a Caribbean prevalence estimate. This article does not verify the previously claimed country loss totals, business-survey percentages, attack costs or recovery rates.

Small businesses should assess their own exposure: who can add a payee, how payments are approved, how much can leave before someone notices and whether alerts reach a person able to act. Do not assume that a country’s total banking-fraud figure measures losses caused by deepfakes.

A suggested 30-day review

Use the month to organise work and identify gaps. Completion is not a security certification, and urgent weaknesses should not wait for their scheduled week. A qualified IT provider can help with changes your team cannot safely implement.

Week 1: account access

List the email, banking and administrator accounts involved in payments. Remove access that is no longer needed.
Enable MFA where available and prefer phishing-resistant FIDO/WebAuthn methods for sensitive access. NIST explains why code-based MFA remains susceptible to phishing.
Check recovery settings and identify who can regain control if an account is compromised. Avoid shared credentials.
Ask the email administrator to review authentication, filtering and suspicious forwarding. Do not change live security settings without an agreed recovery route.

Week 2: payment approval

Document independent verification for new payees, changed account details and unusual payment requests. The FBI’s BEC guidance recommends verifying changes and contacting the organisation outside the suspicious message.
Use a second authorised reviewer where practicable, with access to the invoice and verification record. If one person runs the business, ask the bank about limits, holds and other available checks.
Test transaction alerts and confirm who receives them. An alert after a transfer is not the same as preventing it.
If using a shared phrase, keep it as an additional check only. A leaked or replayed phrase must not override independent verification.

Week 3: staff practice

Rehearse a fictional payment request, a supplier-account change and an attempted override by a supposed executive. Include the owner and senior staff.
Use synthetic data and consented training material. Do not upload customer records or clone a colleague’s voice without permission.
Make reporting straightforward and avoid blaming someone for raising a concern. Check whether they can pause work without losing their place in the process.
Record the steps that failed, repair them and repeat the exercise. A small simulation cannot establish the likelihood of future losses.

Week 4: response and recovery

Prepare a short contact sheet covering the bank, IT responder, leadership and applicable reporting routes. Keep it available outside the main email account.
Rehearse how to stop further payments and contain a compromised account without deleting evidence.
Check backup restoration and the fallback for essential business work. Use NIST’s small-business guide to identify broader gaps beyond payment fraud.
If you hold insurance, check notification requirements, exclusions and limits with the insurer or broker. Do not assume a policy covers an authorised transfer induced by deception.

Know where to report

For suspected payment fraud, contact your bank through its official app, statement or another independently verified channel. For a crime report, confirm the appropriate local police route. Technical incident assistance and legally required notifications may involve different organisations.

Jamaica’s CIRT and Trinidad and Tobago’s CSIRT publish incident-reporting pages. In other jurisdictions, establish the relevant official contacts before an incident. Check their remit and submission requirements. A CIRT report should not be assumed to replace a police report or a data-protection notification.

Ask a locally qualified adviser about statutory and contractual deadlines, particularly where personal data is involved. A list of law titles is not enough to determine which duties apply.

If a payment may already have been sent

Act promptly rather than waiting to prove that AI was involved. The following priorities may need to run in parallel:

Contact the bank immediately. Ask what can be done to stop or recall the payment and alert the receiving institution. Supply the transaction details through a verified channel. Recovery or a freeze is not guaranteed.
Bring in the authorised IT responder. Have them contain affected accounts and devices using the provider’s incident procedure. Password changes alone may leave other access in place. Microsoft’s compromised-email guidance includes session revocation and checks for unauthorised forwarding.
Preserve relevant evidence. Retain original messages, transaction records and available logs securely. Avoid deleting, wiping or publicly circulating material. Coordinate evidence collection with the responder and observe applicable privacy and retention duties.
Make the required reports. Notify leadership, police, relevant authorities and the insurer as applicable. Get advice on deadlines and affected-person communications. Keep a record of the steps taken.

There is no universal “first hour” recovery rate. Speed matters, but the payment method, receiving institution and circumstances affect what can be recovered.

Frequently asked questions

Can we detect a deepfake during a video call? Do not make payment approval depend on spotting visual or vocal defects. A realistic image is not proof of identity, and a glitch is not proof of fraud. Leave the call and verify the requested action through an established independent route.

Will the bank reimburse us? Do not assume either reimbursement or refusal. Ask the bank about the specific transaction, account terms, dispute process and applicable protections. Obtain local legal advice if the outcome is disputed.

Does being technically skilled make someone safe from impersonation? Do not exempt anyone from the payment procedure. The owner and technical staff should follow the same verification rules as other approvers.

Is this proportionate for a ten-person business? Start with the permissions and payments that could cause material harm. Check the time, cost and staffing needed for each control. A smaller business may need a different approval arrangement, but still needs a way to hold an uncertain request.

Must we buy an AI fraud detector? First test the controls you already have. Ask any prospective supplier for evidence relevant to your systems, false alarms, missed attacks and operational support. No detector should be the sole basis for authorising a payment.

Part of the AI Playbook for Caribbean and LATAM Micro and Small Businesses. Created by Adrian Dunkley, MaestrosAI. Educational resource, fair use.