Article
A $1.9M Jail Vendor Scam Ran for Months Before Anyone Caught It
Pulaski County, Arkansas paid roughly $1.9 million to a fraudster over several months in 2026 after accounts payable staff updated a vendor's bank account based on a single email, according to the county's own account. Nobody called the vendor to confirm the change before the money moved, and nobody checked again on any of the following payments. That is the entire failure, and it is a common one: a banking-change request arrived, it looked routine, and it was never verified out-of-band.
What happened in the Pulaski County jail vendor fraud?
On June 19, 2026, Pulaski County's sheriff's office received an email that appeared to come from an accounts-receivable representative at Turn Key Health Clinics, LLC, the company that has provided medical services at the county's detention center for roughly a decade. The email asked the county to move Turn Key's payments to ACH and update its bank information. Sheriff's office staff forwarded the request to the county's accounts payable department, which updated the banking details in the payment system. The treasurer's office then used the new account for every subsequent Turn Key payment.
For four months, nobody flagged anything wrong. The scheme only surfaced on October 23, when a real Turn Key representative contacted the sheriff's office asking why the company hadn't been paid in months, according to reporting from Arkansas outlet KATV. The county's IT team reviewed the original June email and concluded it was fraudulent. By then, approximately $1.9 million in public funds had gone to the fraudster's account. The county recovered the most recent payment of $126,344.87 immediately, and by October 31 announced it had recovered the full $1.9 million in coordination with the treasurer's office, though the investigation remains open with the FBI involved.
This is a textbook business email compromise (BEC): a request that mimics a known vendor, asks for a routine-sounding change, and relies on nobody picking up the phone. If this pattern looks familiar, it should: this site has covered the same mechanics in the FBI's 2025 BEC numbers and in a nearly identical Alabama government vendor scam.
Why didn't the county's existing verification process catch it?
Because the verification that did happen checked the wrong thing. Reporting from the Arkansas Democrat-Gazette describes a treasurer's office that confirmed the new account was a real account at a real bank, a process the office's director of operations said is limited to "setting up the bank and routing information for county payments." Nobody in that chain confirmed the account belonged to Turn Key, because no one owned that step. The request passed through three county divisions, each reporting to a different executive, and each did its own narrow part of the job without anyone treating vendor-identity confirmation as its own control.
That gap is common, not unusual. Most AP teams verify a vendor once, at onboarding, when a W-9 and voided check come in together and someone checks a box. The verification almost never repeats when a vendor later asks to change its bank details, even though a changed bank account on an established vendor is a far riskier event than a new vendor showing up. The Association of Certified Fraud Examiners' 2024 Report to the Nations found that the typical occupational fraud case runs about 12 months before anyone catches it, close to the several months Turn Key's payments were diverted before a vendor, not an internal control, caught it.
Why is a bank-change request the single highest-risk signal in AP?
A bank-change request on an existing vendor deserves more scrutiny than almost anything else that crosses an AP desk, for a simple reason: it carries all the trust of an approved vendor relationship with none of the verification that relationship was built on. The invoice amount looks normal. The vendor name matches. The PO or contract reference, if one exists, checks out. The only thing that changed is a 9-to-17 digit string nobody reads twice. Fraudsters know this, which is why vendor-impersonation and payment-redirect emails are built around exactly this moment rather than around fabricating an entirely new, unfamiliar vendor.
ACFE's own benchmark data on how fraud gets caught makes the same point from a different angle. In ACFE's 2020 Report to the Nations, employees generated half of all fraud tips, customers another 22%, and vendors just 11%, meaning internal controls, not an outside party noticing, are usually what has to catch this kind of fraud before the money is gone. In Pulaski County's case, the vendor eventually did notice, but only after four months and $1.9 million. Waiting on the vendor to flag a missing payment is not a control; it is what happens when there isn't one.
How do you build a revalidation cadence for recurring vendors?
The fix is not a better onboarding form. It's treating a bank-change request as a distinct, higher-risk event than routine invoice processing, with its own checklist every single time:
- Separate the request from the verification. Whoever processes the change (AP) should never be the only person who confirms it's legitimate. Someone who didn't touch the email does the verification call.
- Call a number you already have on file, never one in the request. The email, the letterhead, and any phone number included in a banking-change message should all be treated as unverified. Pull the vendor's phone number from your own vendor master record or a past signed contract.
- Confirm with a named person, not a general mailbox. Ask for whoever normally handles the account on the vendor's side, by name, and if you don't reach them, don't proceed until you do.
- Hold the first payment on the new account for a short delay if your cash flow allows it. A short hold gives a second reviewer time to look at the change before real money moves.
- Put an expiration on "verified." A bank account confirmed once in 2022 isn't confirmed in 2026. Build a cadence, for example confirming active, recurring vendors' banking details every 6 to 12 months even without a change request, so a dormant control doesn't quietly age out.
None of this is complicated. It's also exactly the set of steps that didn't happen here, because the task was split across three county departments and no one owned the specific job of confirming the account belonged to Turn Key.
What should happen the moment a banking-change request arrives?
Treat it like a fire drill, not paperwork. The sequence that would have stopped the Pulaski County loss:
- Flag the change before it's applied. Don't let a single staff member update live banking details and have payments go out the same cycle.
- Verify out-of-band, immediately. Call the vendor using a known-good number, not anything in the email. If you can't reach the right person same-day, the change waits.
- Check the request against what you'd expect. Does this vendor usually email AR change requests, or does it call? Is the new bank in a different state or country than the old one? Mismatches are a reason to slow down, not proceed.
- Log who verified it, how, and when. If the verification step isn't documented, it's hard to prove it happened at all, and hard to audit afterward.
- Re-run the same check on the next invoice cycle. A one-time confirmation covers one change. If the account changes again, repeat the whole process.
| Verification approach | Catches a mid-year bank swap? | Catches a well-crafted BEC email? | Effort per change |
|---|---|---|---|
| One-time check at vendor onboarding only | No | No | Lowest |
| Annual mass revalidation of all vendors | Only if the change falls near the annual date | Partial | Low |
| Out-of-band call on every banking-change request | Yes | Yes | Moderate, but only on changes |
| Agreement-aware AP automation that flags every banking change against the vendor's record on file | Yes | Yes, flags it before posting | Low, ongoing |
A related gap shows up even without fraud involved: only 18% of firms continuously revalidate vendor bank details rather than checking once and moving on. Pulaski County's process matches that majority pattern closely.
Where does this fit for a team that can't staff a dedicated fraud review?
Most AP teams in the 10-500 staff range don't have a security team, and adding a dedicated fraud reviewer for every banking change isn't realistic at lower invoice volumes. The honest threshold: structured controls like a revalidation cadence pay for themselves once a team is processing enough recurring vendor payments that a human reviewer can't realistically remember when every vendor's bank details were last confirmed, which tends to show up well under the roughly 200 invoices a month where broader AP automation ROI starts to clearly justify itself. Below that, a documented checklist and a calendar reminder may be enough. Above it, the job is less about availability and more about whether someone remembers, every time, to treat a bank change differently than a routine bill. Software that absorbs that specific check before the next hire, rather than replacing the person approving payments, is the practical middle ground. Quittance, for example, flags a changed bank account on a recurring vendor as one of its fraud signals before an invoice posts, so the check doesn't depend on someone remembering to run it. A human still approves every payment; the system's job is just to make sure the banking-change flag never gets skipped.
FAQ: verifying vendor bank details without slowing payments down
Is every vendor bank-change request fraudulent? No. Vendors switch banks for ordinary reasons, including mergers, new accounting providers, or simply moving banks. The point of verification isn't to assume fraud, it's to confirm the request came from the vendor before acting on it, using a contact method you already trust rather than anything included in the request itself.
How often should a company revalidate vendor bank details? There's no universal rule, but confirming active, recurring vendors' banking details on a fixed cadence, such as every 6 to 12 months, and on every change request, closes the gap that a one-time onboarding check leaves open. The Pulaski County case shows what four months of relying on a single unverified change can cost.
What does "out-of-band" verification mean? It means confirming a request through a different channel than the one it arrived on, using a contact method pulled from your own records rather than from the request. If the change request came by email, you verify by phone, using a number from your vendor file, not a number in the email.
Does verifying every bank change slow down payments? A same-day phone call rarely delays a payment cycle meaningfully, especially against the alternative. Holding the first payment on a newly changed account for a short review window costs far less time than recovering a loss after the fact, and in Pulaski County's case, no one caught the change for four months because no one checked.
Who should own vendor bank verification on a small AP team? Whoever didn't process the original request. The core control is separation: the person updating banking details in the system shouldn't be the only person confirming the change is legitimate, even on a two- or three-person AP team.
Can accounting software catch a fraudulent bank change automatically? Software can flag that a vendor's banking details changed and hold the payment for review, which closes the gap where a changed account quietly becomes the new normal. It does not replace confirming the change with the vendor directly; that verification step still needs a person to make the call.