Healthcare pays by EFT. Changing the EFT is a phone call and a form.

A practice does not find out that its payments were redirected on the day it happens. It finds out three weeks later, during reconciliation, when someone notices that a payer which deposits money every Tuesday has stopped. By then the window has closed. This is a walk through why healthcare payment diversion is unusually slow to detect, why the practice is the wrong party to fix it, and what a control at the payer's enrolment endpoint would actually look like.

The Tuesday deposit that stopped arriving

Picture the billing office of a twelve physician orthopaedic group. Not a hospital, not a solo practice, the awkward middle where there is a real revenue cycle operation but no security team. Payments arrive by electronic funds transfer from a dozen payers on their own rhythms. One of them, a large commercial plan, deposits most Tuesdays. The remittance advice arrives separately, sometimes through the clearinghouse portal, sometimes as a file the practice management system ingests overnight.

In the second week of a month, someone sends the practice's billing manager an email that looks like it comes from that payer's provider relations team. It refers to a real initiative, because the payer announced one publicly. It asks the practice to confirm its electronic payment details through a portal, and the portal looks exactly like the one the billing manager uses. She signs in. Nothing appears to happen. She assumes the link was stale, closes the tab, and gets on with her afternoon.

What happened is that her credentials were relayed to the real portal in real time, and the session that resulted did not belong to her. Somebody submitted an electronic funds transfer change on the practice's account: new routing number, new account number, effective immediately. The payer's system received a properly formed change request from an authenticated session belonging to a user with the authority to make it. It did what it was built to do. It applied the change and sent a confirmation to the address on file, which by then had a mailbox rule filing anything containing the word "enrollment" straight into a folder nobody opens.

The following Tuesday, no deposit. Nobody notices, because deposits move around, because a holiday fell that week, because the practice is chasing a denial backlog. The Tuesday after that, still nothing. In the third week the controller runs the aging report properly, sees a payer whose receipts have gone to zero while claims are still adjudicating and marking as paid, and the room goes quiet.

What is provider EFT diversion?

Every payer that reimburses a healthcare provider electronically holds a record of where to send the money. For Medicare that record is established through an authorisation agreement and maintained in the enrolment system used by the Medicare Administrative Contractor for that jurisdiction. For Medicaid it is a state agency process. For commercial plans it is a provider portal, sometimes operated by the payer and sometimes by a clearinghouse acting on its behalf. The details differ. The shape does not: there is a stored destination, and there is a process for changing it.

Provider EFT diversion is the fraud of changing that stored destination. It is not sophisticated. It does not require breaking anything. The attacker needs one of two things: the ability to submit a change through the portal, which credential phishing supplies, or the ability to submit a change on paper or by fax that the payer's enrolment staff will process, which convincing letterhead and a plausible cover story supply. Both routes end at the same place, which is a change request that looks exactly like the hundreds of legitimate change requests the payer processes every week.

This is the vendor bank change pattern, wearing scrubs

If you have read the piece on vendor email compromise, you already know the mechanism, and this post will not repeat it. The attacker does not steal money. The attacker changes a stored number, and the victim's own systems then send the money voluntarily, on schedule, through legitimate rails, for as long as nobody looks. It is the same fraud that redirects supplier payments and the same fraud that redirects a salary in payroll diversion.

What is worth a separate post is not the mechanism but the three properties that make the healthcare instance behave differently, one of which is the reason this fraud is unusually profitable.

Why is healthcare different from ordinary vendor payment fraud?

The relationship is regulatory, not commercial

When a manufacturer pays a supplier, the two parties chose each other and can restructure the relationship at will. When a payer pays a provider, the relationship runs through an enrolment regime with defined forms, identifiers and processes. That formality is usually a strength. Here it works against the provider, because the process is standardised and documented in public, so an attacker can learn exactly what a legitimate change request looks like without compromising anything. The forms are published. The identifiers, including the National Provider Identifier, are in public directories.

The payments are recurring and large

A supplier gets paid when it invoices. A provider gets paid continuously, as claims adjudicate, in a stream that does not stop. A practice does not lose one payment to this fraud. It loses every payment from that payer until somebody notices, which turns a single successful change into an annuity for the attacker. For a mid sized group, a single payer relationship can represent tens of thousands of dollars a week.

And nobody is looking, because reconciliation runs behind

This is the property that matters most, and it deserves its own section.

Why is the reconciliation lag the real vulnerability?

In most fraud, detection is bounded by how quickly the victim notices an absence. A consumer notices a missing paycheque on payday. A supplier notices a missing payment when it chases the invoice. In both cases somebody is waiting for a specific amount on a specific day, and its absence is legible immediately.

Healthcare revenue cycle does not work like that. The amount is not known in advance, because it depends on adjudication. The date is not known in advance, because it depends on the payer's cycle. The reconciliation itself is a matching problem: remittance advice arrives on one channel, deposits arrive on another, and the work of tying them together is done in batches, often weekly, sometimes less often when the team is short staffed and denials are stacking up. Payment variance is the normal condition of the job.

So the signal that would give the game away, which is money not arriving, is buried inside a process that is designed to tolerate exactly that noise. The practice is not being careless. It is doing a job whose ordinary state is a partially reconciled ledger.

Think of a leak in a pipe running under a field you cross once a fortnight. The leak is not subtle. It is simply somewhere nobody is standing. By the time anyone stands in the right place, the funds have moved through several hops and out of reach. Recovery in payment redirection cases depends almost entirely on speed, and this fraud is optimised against speed by the shape of the victim's own operations.

How big is this problem?

Here is where an honest post has to say something that a vendor post usually does not. There is no reliable public figure for healthcare EFT diversion specifically, and anyone who quotes you one should be asked where it came from.

What can be established is the parent category and the surrounding context.

Business email compromise, the family of frauds that payment redirection belongs to, accounted for roughly 3.05 billion dollars in reported United States losses across 24,768 complaints in 2025, with about 86 percent of that money moving by wire or ACH (FBI Internet Crime Complaint Center, 2025 Internet Crime Report). That is the reported figure, and reported figures in this category are understood to be a floor, because many organisations resolve losses privately and never file.

Separately, the Government Accountability Office reported that federal agencies estimated roughly 186 billion dollars in improper payments across dozens of programmes in fiscal year 2025 (GAO-26-108694). Be precise about what that figure is not. Improper payments are overwhelmingly eligibility and documentation errors rather than fraud, and payment to a wrong party is one small category within it. It is offered here only as context for the scale of these payment streams and the scrutiny payment integrity now attracts.

Beyond that, the record is fragmentary. Payers and their contractors publish provider facing guidance about protecting enrolment credentials, which tells you the category is real and recognised, and individual cases surface through prosecutions and trade press. What does not exist, as far as we can determine, is a systematic accounting. The reason is structural: the loss lands on the provider, is often settled quietly, is categorised inconsistently when reported at all, and has no dedicated reporting channel that would aggregate it.

That absence is itself a finding. A fraud that nobody counts is a fraud that nobody budgets against.

Why existing solutions fail

Every control currently deployed against this sits on one side or other of the change, and none of them sits on the change itself.

Portal multi factor authentication protects the login

Requiring a second factor at portal sign in is a genuine improvement and every payer should do it. It is also the control that the attack in the opening scene defeats by construction. An adversary in the middle phishing kit relays the victim's authentication to the real portal and captures the resulting session, so the second factor is satisfied by the real user, on the real page, and the attacker inherits what comes out the other end. The session theft piece covers this in detail. The short version is that authenticating the session says nothing about who submits the next form.

Confirmation letters and callbacks use channels the attacker already holds

The standard secondary control is to notify the provider that a change was made, or to telephone to confirm it. Both use the contact details on the record being changed, or details supplied in the request itself. A mailbox rule handles the letter. A number in the request handles the call. This is the same failure examined at length in the callback verification post, and it applies here with extra force because healthcare enrolment records contain multiple contact points that are themselves editable through the same portal.

Periodic re-attestation is periodic

Some payers require providers to re-attest to enrolment details on a cycle. This is useful for data hygiene and nearly useless here, because the entire loss occurs between attestations. A control that runs annually against an attack paying out weekly is not a control, it is a record keeping exercise.

And the staff processing the change cannot tell

This is the part that deserves sympathy rather than criticism. Payer enrolment teams and provider revenue cycle teams are both processing high volumes of routine paperwork under time pressure. A legitimate EFT change and a fraudulent one arrive through the same channel, on the same form, with the same identifiers, and differ only in a string of digits that the processor has no independent means of checking. Asking that person to detect the fraud is asking them to do something the information in front of them does not support. The failure is a design failure, not a diligence failure.

Who can actually fix this?

The reflex in this category is to publish provider awareness material. Train the billing staff. Warn them about phishing. Tell them to check the sender address.

That reflex misplaces the control. Consider who does what in this transaction. The provider requests a change. The payer executes it. The money moves because the payer's system was instructed to move it. The provider cannot prevent the payer from applying a fraudulent instruction, and no amount of provider side training changes that, because the provider is not in the loop at the moment the change is applied. Training reduces the probability that a particular billing manager gets phished on a particular day. It does nothing about the hundreds of other practices whose staff will be phished this year, and it does nothing at all about the paper and fax route.

The payer is the only party that can require proof, because the payer is the party that executes the change. That is the argument of this post, and it is a slightly uncomfortable one for the industry, because it moves a cost from the party currently absorbing the loss to the party currently processing the form.

The counter argument deserves a fair hearing. Payers process enormous volumes of enrolment changes, and any additional requirement carries operational cost borne across every legitimate provider to stop a fraud affecting a small fraction of them. Providers range from health systems with security teams to solo practitioners, and a control a solo practitioner cannot complete generates support calls and abandoned enrolments. These are genuine objections. They argue for a design that is fast and works on a phone, not for leaving the endpoint unguarded.

What does a signed enrolment change look like?

The mechanism is the same one this series applies to every high consequence action. Instead of asking whether a request is trustworthy, require the request to carry something only the right human can produce.

Concretely: the practice designates an authorised official, the same role the enrolment regime already contemplates, and that person enrols a device once. From then on, the payer's enrolment change endpoint refuses to apply a payment information change unless the request carries a fresh cryptographic signature from that person's enrolled device, covering the exact contents of the change.

What actually gets signed

The important design point is that the signature covers the payload, not merely the session. A signature over "the user approved something" is worth very little. A signature over the specific new account details is worth a great deal, because it cannot be replayed against a different change.

{
  "action":              "eft.enrollment.change",
  "payer":               "commercial-plan-4417",
  "provider_npi":        "1234567890",
  "tin_last4":           "8842",
  "current_account_sha": "9f2b41c0e7d3a58b...c41d",
  "new_routing":         "021000021",
  "new_account_last4":   "8830",
  "effective_date":      "2026-10-15",
  "authorised_official": "official:ada-okonkwo",
  "issued_at":           "2026-10-01T14:22:07Z",
  "nonce":               "1f0c9d3e5a77b204"
}

That object is canonicalised, hashed, and the hash becomes the challenge the authorised official's device signs. The nonce and the timestamp make the signature single use. The hash of the current account details ties the change to the state it is replacing, so a signature captured for one change cannot authorise a later one. The signature and the payload together form a receipt.

What the payer's endpoint does with it

def apply_eft_change(request, receipt):
    payload = canonical(request.payload)
    if sha256(payload) != receipt.challenge:
        return reject("payload does not match signature")
    if not verify_ed25519(receipt.signature,
                          receipt.challenge,
                          published_key(receipt.signer)):
        return reject("signature does not verify")
    if receipt.signer not in authorised_officials(request.provider_npi):
        return reject("signer is not an authorised official")
    if receipt.age() > timedelta(minutes=15):
        return reject("signature is stale")
    if seen_before(receipt.nonce):
        return reject("replayed signature")
    persist(request, receipt)      # receipt filed with the enrolment record
    return apply(request)

Note what this does not do. It does not attempt to judge whether the request looks suspicious. It does not score anything. It asks one question with a cryptographic answer: did the enrolled authorised official sign this exact change in the last few minutes. The phished session cannot produce that signature, because the signing key never left the official's device and was never part of what the phishing kit captured. Neither can the fax.

And afterwards, the receipt is the evidence

The receipt is stored with the enrolment record and verifies offline against a published key, which means an auditor reviewing payment integrity years later can confirm that a specific human authorised a specific change without contacting anyone, without a live system, and without trusting the payer's own logs. That property matters more in a regulated payment stream than it does in commercial accounts payable, because payment integrity review is a routine and adversarial exercise here. It is the same argument made in the audit trail design piece: a log an organisation writes about itself is weaker evidence than an artifact a third party produced.

Where does the control sit in the enrolment path?

The clearinghouse row is the one worth dwelling on. A practice that submits enrolment changes to eight payers through one clearinghouse has one place where a control could be applied that would cover all eight. That is why the realistic path to adoption here runs through clearinghouses and revenue cycle platforms rather than payer by payer.

What are the honest limits?

This post would be dishonest if it implied broader applicability than the mechanism has, so here is the boundary, stated plainly.

• Medicare and Medicaid systems cannot be modified by a private vendor. Enrolment for federal and state programmes runs through government systems and contractors operating under federal procurement. Nobody ships a control into those systems by writing a blog post or signing a commercial contract. For that segment, this is a policy argument addressed to the agencies, not a product proposal.
• The realistic near term scope is commercial payers, clearinghouses, revenue cycle platforms, and health system accounts payable. That is a meaningful share of provider payments and it is not all of them.
• Enrolment of the authorised official is the trust bottleneck. Everything rests on the first binding between a real person at the practice and a key. An attacker who controls that moment controls everything after it, which is why the enrolment step deserves more care than the ongoing use.
• Practices have turnover, and the authorised official leaves. Transferring the role needs a defined path that is not itself a soft target, the same problem examined in the offboarding piece.
• Billing companies act for practices legitimately. Many small practices outsource revenue cycle entirely, so the model must support explicit, scoped delegation to a billing company rather than pretending the intermediary does not exist.
• This does not touch other payment integrity problems. Upcoding, phantom billing and eligibility fraud are different failures with different remedies. This addresses one narrow thing: who may change where the money goes.
• Manav has shipped no payer or clearinghouse integrations. The signing and receipt primitives are real and available today through the API. Native connectors into enrolment systems are not built, and describing them as though they were would be exactly the overclaiming this series criticises elsewhere.

What to do this week

Split by who you are.

If you run revenue cycle at a provider:

1. List every payer that pays you electronically and write down, for each, the exact process by which its EFT details could be changed. Most teams have never enumerated this and are surprised by how many routes exist.
2. Calculate your exposure honestly: average daily receipts from your largest payer, multiplied by your realistic days to detection. Use your actual reconciliation cadence, not your intended one. That number is the size of a single successful change.
3. Shorten the detection window rather than assuming you can prevent the change. A daily automated check for expected deposits that did not arrive is cheap and cuts the window from weeks to days.
4. Turn on every alert the payer portals offer, and route those alerts somewhere other than the mailbox that would be compromised, ideally to a second person.
5. Ask each payer, in writing, what they require before applying an EFT change. The answers will vary more than you expect, and the written record is useful if you ever have to argue about liability.

If you run a payer, clearinghouse or revenue cycle platform:

1. Instrument the enrolment change endpoint and find out how many payment information changes you process, how many are later reversed, and how many arrive within a short window of a password reset or a new device sign in. Most organisations have never looked at that correlation.
2. Classify enrolment fields by consequence. A change of practice address and a change of bank account are not the same risk and should not share a control.
3. Add a hold on the first payment following a bank detail change, if you do not have one. It delays rather than prevents, and delay is worth real money here given the detection lag.
4. Design the authorised official signing flow before you need it, including the outsourced billing company and the departure cases, because that is where such schemes usually fail in practice.

If you want to see the signing and receipt mechanics rather than read about them, the signing demo shows a payload being signed and verified offline, and the developer documentation covers the API.

Frequently asked questions

What is provider EFT diversion? It is the fraud of changing the bank account details a payer holds for a healthcare provider, so that claim payments are redirected to an account the attacker controls. The attacker usually submits the change through a phished provider portal session or on convincing paperwork. The payments then continue to flow to the wrong account until the practice notices a shortfall during reconciliation, often weeks later.

How do payers verify payment information changes today? Most rely on some combination of portal authentication, a confirmation letter or email to the contact details on the record, a callback to a number on file, and periodic re-attestation. Each of these either uses a channel the attacker may already control or runs on a cycle far slower than the fraud, which is why a change submitted from a valid session is generally applied.

Why does it take so long for a practice to notice? Healthcare reconciliation matches remittance advice against deposits in batches, and both the amount and the date of any given payment vary by adjudication. Payment variance is the normal state of the ledger, so an absent deposit does not stand out the way a missed payroll or an unpaid invoice would. That tolerance for noise is what gives the attacker weeks rather than days.

Is multi factor authentication on the payer portal enough? No, though every payer should still require it. Adversary in the middle phishing relays the victim's authentication to the genuine portal in real time and captures the resulting session, so the second factor is satisfied by the real user and the attacker inherits an authenticated session. The fix has to bind the authorisation to the specific change rather than to the login.

How much money is lost to healthcare EFT diversion each year? Nobody knows, and any specific figure should be treated with suspicion. Business email compromise as a whole accounted for about 3.05 billion dollars in reported United States losses in 2025 (FBI Internet Crime Complaint Center), but no public source isolates the healthcare payment redirection subcategory. The absence of a number is one reason the problem is under addressed.

Whose responsibility is it to prevent this? Practically, the payer or clearinghouse that executes the change, because it is the only party present at the moment the change is applied. Provider awareness training reduces the odds for one practice on one day and cannot address the paper route or the next practice. Moving the control to the endpoint that performs the action is the structural fix.

Can this be applied to Medicare and Medicaid enrolment? Not by a private vendor. Federal and state enrolment systems are operated by agencies and their contractors, so for that segment this is a policy recommendation rather than something a provider or a technology supplier can implement. Commercial payers, clearinghouses and revenue cycle platforms can act without waiting for anyone.

Sources

1. Federal Bureau of Investigation, Internet Crime Complaint Center, 2025 Internet Crime Report, for business email compromise losses and the share moving by wire and ACH. https://www.ic3.gov/AnnualReport/Reports
2. United States Government Accountability Office, report GAO-26-108694 on federal improper payments in fiscal year 2025, cited for programme scale and payment integrity context only, not as a measure of fraud. https://www.gao.gov/
3. Centers for Medicare and Medicaid Services, provider enrolment materials including the electronic funds transfer authorisation agreement and the Provider Enrollment, Chain and Ownership System. https://www.cms.gov/medicare/enrollment-renewal
4. United States Department of Health and Human Services, Office of Inspector General, provider and consumer alerts index. https://oig.hhs.gov/fraud/consumer-alerts/
5. Microsoft Security Blog, research on adversary in the middle phishing and session token theft, for the mechanism by which portal authentication is defeated. https://www.microsoft.com/en-us/security/blog/

The practice cannot stop the payer from applying a fraudulent change, because the practice is not in the room when it happens. Put the control where the action is.