AI-Written Phishing and Wire Fraud: Protecting Nonprofit Payment Approvals

What This Actually Looks Like Inside a Nonprofit

Generic security awareness training describes BEC in the abstract. It is more useful to walk through the specific shapes it takes in an organization with a small finance function, a mixed roster of vendors, grant money moving in and program money moving out, and a staff directory published on the website.

Vendor invoice fraud and the bank change request. This is the most expensive variant and the one that succeeds most often, because it exploits a routine that is genuinely routine. An email arrives from your janitorial contractor, your IT consultant, or your fiscal agent, referencing a real invoice number, saying they have changed banks and asking you to update the remittance details before the next payment. The message may come from a spoofed address, from a lookalike domain that differs by one character, or from the vendor's actual compromised mailbox, which is the version that defeats every check based on where the message came from. In the compromised-mailbox case the criminal has often been reading the thread for weeks, which is why the invoice number is right and the tone matches.

Payroll diversion. A message purporting to come from an employee asks HR or the payroll administrator to redirect direct deposit to a new account, typically timed a few days before a pay run. The amounts are smaller than vendor fraud but the detection window is worse, because the victim is the employee who does not discover the problem until payday, by which point the funds have usually been moved to prepaid cards. Organizations that accept payroll changes by email, without a second channel, have effectively published an instruction manual.

The gift card request. A short, urgent, casual message appears to come from the executive director, often from a personal-looking address, saying they are in a board meeting and need someone to pick up gift cards for a staff appreciation gesture or a client emergency, and that they will reimburse. The individual losses are modest, a few thousand dollars at most, but the attack costs nearly nothing to run at volume and it lands disproportionately on small organizations where the executive director genuinely does send informal asks. It also functions as reconnaissance: an organization that pays the gift card request is an organization that will probably pay the wire request.

Fake grant and disbursement notices. This variant is specific to the sector. A message arrives announcing an award, a disbursement, or a matching gift, and asks the organization to confirm banking details, pay a processing or verification fee, or click through to a portal to accept the funds. The portal collects credentials, which are then used for the real attack. Organizations in the middle of an active funding round are more susceptible because an unexpected award notice is plausible, and the message can be written to reference a funder the organization has genuinely applied to, information that is often public.

Compromised fiscal sponsors, partners, and board members. The hardest version to catch involves no impersonation at all. A partner organization, a fiscal sponsor, or a board member has their mailbox compromised, and the criminal sends from inside a real, trusted, authenticated account. Every technical control keyed to authenticity passes, because the message is authentic. Only the instruction is fraudulent. This is why verification has to attach to the request type rather than to the apparent identity of the sender.

Increasingly these text-based approaches arrive alongside synthetic voice. A finance director receives the emailed bank change request, calls to confirm using the number in the email signature, and speaks to a cloned voice that confirms it. Our article on what happens when AI fakes your executive director covers the voice and video side of this in depth. The defense against both is the same and it is worth stating now: the number you call must come from your own records, never from the message you are verifying.

The Control That Actually Stops This

If an organization implements exactly one thing from this article, it should be a documented out-of-band verification callback on every change to payment details, paired with a dual approval threshold on outbound payments. Everything else in this article reduces exposure. This is the control that breaks the attack itself, because it forces the criminal to compromise a second, unrelated channel that they almost never have.

Out-of-band means the verification travels over a different channel than the request. If the request arrives by email, the verification happens by telephone. Replying to the email is not verification, because if the mailbox is compromised the criminal is reading the replies and will answer helpfully. The distinguishing detail, and the one organizations most often get wrong, is where the phone number comes from. It must come from your own vendor file, your signed contract, or a record you established at onboarding. A number in the email signature, in the invoice PDF, or on a webpage the email linked to is part of the attack surface. Criminals include a real-sounding number precisely because they expect you to call it.

The callback has to be logged to be a control rather than a habit. A one-line record naming the date, the person called, the number used, the source of that number, the detail confirmed, and who performed the callback turns an individual's diligence into organizational evidence. That log is what an auditor looks at, what an insurer asks for after a claim, and what tells you six months later whether the practice survived a staffing change. Organizations that verify diligently but record nothing discover during an insurance claim that diligence they cannot document is treated as diligence that did not happen.

Dual approval is the companion control, and it works only if the second approver is doing something more than clicking. Two people reviewing the same email are not a control, they are one control experienced twice. A meaningful second approval means the approver independently checks the payee against the approved vendor file, confirms the bank details match what is on record, and confirms that any change was verified by callback. Set a dollar threshold appropriate to your organization rather than importing someone else's, and set a separate, lower threshold for new payees and first-time wires, because those carry more risk per dollar than an established recurring payment.

The rule also has to bind upward, which is the part that gets negotiated away. An exception for the executive director, or a provision allowing urgency to waive verification, is not a small softening. It is the exact hole the attack is designed to find, because impersonating the executive director and manufacturing urgency are the two things the attacker does best. The strongest version of this policy is one the executive director signs and then visibly submits to, including the time they genuinely are on a plane and genuinely do need something paid. Staff read what leadership does far more accurately than what leadership writes.

Build the verification into vendor onboarding rather than bolting it on at payment time. Capture and confirm banking details through a controlled process at the start of the relationship, record a verification phone number at that point, and treat every subsequent change as an exception requiring the callback. The discipline described in our guide to nonprofit vendor onboarding pays for itself the first time a convincing bank change request arrives and you already have a trusted number to dial.

Writing a Payment Approval Policy People Will Actually Follow

Most organizations already have a fiscal policies manual, and most of those manuals address payment authority in general terms that predate this threat. The useful document here is short, specific, and operational: two or three pages that a new finance coordinator can read on their first morning and apply on their second. Length is not authority. A forty-page manual nobody opens provides no protection, while a two-page procedure taped inside a cabinet door provides quite a lot.

Start by naming roles rather than people, since people leave and policies should not need rewriting when they do. Define who may initiate a payment, who may approve one at each threshold, who may change vendor master data, and who may release funds at the bank. The critical structural requirement is that changing a vendor's bank details and approving a payment to that vendor are not the same role. If your organization is too small to separate them by person, separate them by requiring an additional approver specifically for master data changes, which can be the executive director or a board treasurer.

Then write the verification trigger list in concrete language, because ambiguity is where compliance dies. Not "verify unusual requests," which asks an inexperienced staff member to make a judgment call under pressure, but "any change to bank details, any first-time payee, any wire above this amount, any gift card purchase, any payment request describing itself as urgent or confidential." The list should be short enough to memorize and specific enough that nobody has to interpret it. Include the sentence that matters most and that policies usually omit: no exception applies for senior leadership or for urgency, and any request claiming otherwise is itself a red flag to be reported.

Write the reporting path next, with a named channel and a promised response. Staff report suspicious messages when reporting is fast, when the answer comes back quickly, and when being wrong costs them nothing. If a report disappears into a shared mailbox for three days, people stop reporting, and the organization loses its best early warning. State plainly that reporting a legitimate message is a correct outcome, not a waste of anyone's time.

Finish with the incident section, which should be written before you need it and kept somewhere accessible when email is down. Name who calls the bank, what number they call, who files the IC3 report, who notifies the insurer, who tells the board chair and the treasurer, and who calls the auditor. A staff member who has just realized they authorized a fraudulent wire is not in a state to improvise a response, and the first hour is when recovery is most possible.

This is a good use of AI assistance. A language model given your organization chart, your current fiscal policy, your bank's available controls, and your approval thresholds will produce a clean first draft in minutes, and will rewrite it at a lower reading level, translate it, or reformat it into a one-page desk reference on request. It will also role-play a new employee reading the policy and tell you which sentences are ambiguous, which is worth more than most policy review meetings. The judgment about thresholds and roles remains yours, and someone with authority still has to approve the result. The same pattern we describe for building an AI acceptable use policy applies directly: the model drafts, the humans decide.

The First 24 Hours After a Fraudulent Payment

Recovery in this kind of fraud is almost entirely a function of speed. Funds sent to a criminal-controlled account are typically moved onward within hours, and once they have left the initial receiving institution the practical chance of getting them back drops sharply. Everything in this section is written on the assumption that the organization is acting the same day, ideally within the first few hours.

Call your bank first, not email them. The first action is a phone call to your bank's fraud department requesting a recall of the wire or a reversal of the ACH transaction, and asking them to contact the receiving institution to freeze the funds. Do this before internal discussion, before drafting an explanation, and before deciding how to tell the board. Minutes matter here in a way they rarely do elsewhere in nonprofit work. Ask the bank explicitly to attempt a SWIFT recall if the transfer was international, and write down the reference numbers they give you, because subsequent steps require them.

File with the FBI's Internet Crime Complaint Center immediately. File at ic3.gov, marking the complaint as a BEC incident and including the full transaction detail: amount, date and time, originating and receiving account and routing numbers, the receiving bank name, any SWIFT reference, and the fraudulent email addresses involved. This filing is what activates the FBI's Recovery Asset Team, which works with receiving financial institutions to freeze funds, and it is the route into the Financial Fraud Kill Chain, a process run with the Treasury Department's Financial Crimes Enforcement Network that can halt international transfers under specific conditions. The Kill Chain applies to international wires at or above $50,000 reported within 72 hours where a recall has been initiated. Those thresholds are real constraints, and the 72-hour clock starts at the transfer, not at the moment you discover it, which is why the bank call and the IC3 filing should happen on the same afternoon. File regardless of whether you meet the thresholds, because smaller and domestic cases still go to the Recovery Asset Team and the data informs enforcement.

Preserve evidence before anyone cleans up. Do not delete the fraudulent messages, and do not let a well-meaning staff member tidy the mailbox. Preserve the messages with their full headers, export the relevant mailbox audit and sign-in logs, capture any inbox rules the attacker created, and note who did what and when. If a mailbox was compromised, reset the credentials, revoke active sessions and tokens, remove attacker-created rules and OAuth consents, and re-enroll MFA. Preserve first, remediate second, because remediation destroys evidence that both your insurer and law enforcement will ask for.

Notify the insurer the same day. Crime and cyber policies carry strict notice requirements, and late notice is a common and entirely avoidable reason claims are reduced or denied. Notify your broker and carrier immediately even if you do not yet know the full facts, and check whether your policy requires the carrier's consent before you engage outside counsel or a forensics firm, because incurring those costs first can make them unrecoverable.

Tell the board chair and treasurer, then the auditor. Board notification should happen the same day for a material loss, not at the next scheduled meeting. Boards handle bad news they hear early far better than bad news they hear late, and a delay converts a fraud incident into a governance incident. Your auditor also needs to know, since fraud affecting the financial statements or federal funds has reporting implications, and an auditor who learns about a loss during fieldwork rather than from you will reasonably ask what else was not disclosed. Organizations that maintain good documentation as a matter of course, along the lines of our guide to audit preparation, find this conversation considerably easier.

Then work out what else was exposed. Determine whether state data breach notification obligations are triggered, which depends on the states where affected individuals reside and on what personal information the compromised account held. If donor or client data sat in a compromised mailbox, the incident is not only a financial one. If the money was restricted grant funding, notify the funder according to the award terms. Finally, notify partners and vendors whose accounts may also have been used, since a compromised mailbox in your organization is a staging point for attacks on everyone you correspond with.

Where AI Helps the Defenders

The uncomfortable framing of this whole topic is that AI made the attacks cheaper and better. That is true, and it is not the whole picture. Several of the defensive tasks that nonprofits skip for lack of capacity are exactly the kind of work language models do well, and the AFP survey cited earlier suggests that very few organizations have started, which makes this unusually available ground.

Drafting the policy and its derivatives. The payment approval policy, the desk reference version, the board summary, the vendor-facing note explaining why you will call to verify bank changes, and the translated versions for a multilingual staff are all short documents that do not get written because they are tedious. A model produces credible first drafts of all of them from a conversation about your thresholds and roles, and rewrites them on request for a different reader. Ask it to identify ambiguous sentences from the perspective of a new hire, and fix what it finds.

Triaging reported messages. When staff forward suspicious email to a shared mailbox, the bottleneck is that nobody has time to look promptly, and slow answers kill the reporting habit. A model can produce a fast structured first assessment: what the message asks for, whether it involves payment details, whether the sending domain resembles a known partner, what pressure tactics appear, and what the reporter should do next. Treat this as triage that speeds a human response, not as a verdict, and never let an automated assessment authorize a payment.

Summarizing logs and audit data. Mailbox audit logs, sign-in logs, and mail flow reports contain the evidence of a compromise and almost nobody at a small nonprofit reads them, because they are large and formatted for machines. Asking a model to summarize a week of sign-in activity and flag impossible travel, new forwarding rules, unusual OAuth consents, and administrative changes converts an unread file into a short list a human can check. The same technique makes DMARC aggregate reports legible, which is often what stalls an organization partway through moving to a reject policy.

Building training scenarios that match your organization. Generic phishing simulation libraries do not contain a lure referencing your actual grant cycle, your actual vendor categories, or your actual program vocabulary. A model given a description of your operations will generate role-specific scenarios in minutes, which is the difference between a monthly two-minute exercise and an annual video. It can also generate the tabletop exercise for leadership, the decision tree for a finance coordinator, and the short explainer of why the callback number cannot come from the email.

Drafting the incident paperwork under pressure. In the hours after a fraudulent payment, someone has to write the IC3 narrative, the notice to the carrier, the message to the board chair, and the chronology for the auditor. These are painful to compose while distressed. A model working from your timeline produces serviceable drafts quickly, which a human then verifies and sends. Be careful about what you paste into a consumer tool at this moment, since account numbers and personal data belong only in a service whose data handling terms you have actually reviewed.

What AI must not do here. It must not approve payments, verify identities, or replace the callback. An automated assistant that reads email and acts on it is a new attack surface rather than a control, and prompt injection through a crafted message is a live risk for any agent with authority over financial systems. Keep the model on drafting, summarizing, and triage, and keep the authorization with a person who can be held accountable. For organizations without internal IT, our guide to securing AI tools without a technology team covers how to set those boundaries in practice.