Vendor Bank Account Monitoring: How to Get Notified About Bank Account Changes
You have verified your supplier's bank account. The ownership check passed. The account belongs to the right entity. The payment went out. Done.
Now the question that almost no one asks out loud — but everyone eventually wonders: what happens if they change their account details next month? Will anyone tell you?
The short answer is no. And understanding why — and what you can do instead — is the difference between a one-time verification exercise and a payment fraud control that actually holds.
The monitoring adoption gap
Most organisations verify vendors at onboarding — almost none monitor them continuously
Why your bank cannot notify you when a vendor's account changes
This is the question finance teams ask and never get a straight answer to. So here it is.
Banks have a contractual relationship with their own account holders — the people and businesses who hold accounts with them. They do not have a relationship with the businesses that send payments to those accounts. When a supplier changes their sort code, account number, or banking provider, their bank notifies them. It has no obligation — and no mechanism — to notify you.
There is no API you can subscribe to. There is no alert you can configure. No bank in any major market — UK, US, EU, APAC — currently offers a commercial payer a push notification for changes to a payee's account. The architecture simply does not work that way.
No such product exists. If a vendor or consultant suggests you can set up a bank alert to be notified when a supplier changes their account, that is not how banking infrastructure works. There is no inbound notification mechanism available to payers. The only way to know whether account details have changed is to check them yourself — on a schedule you control.
Open banking frameworks like PSD2 in Europe have expanded data access significantly since 2018, but the access they provide is still account-holder-initiated. A business can grant a third party access to their own account data. They cannot grant you, as a payer, access to a notification stream for changes to their account. Those are fundamentally different things, and the regulatory architecture does not bridge them.
This is not a gap that is about to close. It would require a structural change to how banking relationships and data sharing are defined — and there is no regulatory proposal in any major jurisdiction that moves in this direction.
Why the gap between verification and next payment is your highest-risk window
Verification at onboarding is table stakes. Most finance teams now do it. What they do not do is treat the period after verification as a risk window — and that is exactly where fraud concentrates.
The fraud pattern is well established. A fraudster identifies a dormant or low-frequency supplier relationship — one where payments happen quarterly, or only on project completion. They intercept a bank change request, or manufacture one, and substitute a fraudulent account. The payment runs. The real supplier follows up weeks or months later about an overdue invoice. By then, multiple payment runs may have cleared.
The reason this works is timing. The verification that happened at onboarding gave the AP team confidence. Nobody re-checked. The fraudster counted on that.
Fraudsters are patient. According to IBM's Cost of a Data Breach report, the average time between a fraud event and its detection is 277 days. That is not a gap — it is nine months of payments flowing to the wrong account. For quarterly suppliers, that could mean three or four payment runs before anyone notices.
How long fraud goes undetected — with and without monitoring
Source: IBM Cost of a Data Breach. Exposure window = maximum time fraud can go undetected at each cadence.
The verification-to-payment gap is also where Nacha's 2026 False Pretenses rules bite hardest. The rules do not only require verification at first payment. They require risk-based monitoring of ACH activity on an ongoing basis. A one-time ownership check at onboarding satisfies the initial verification requirement. It does not satisfy the monitoring requirement. Those are two different obligations.
What this looks like in practice
A mid-market logistics company in the UK paid a haulage contractor quarterly — roughly £85,000 per run. The contractor was verified at onboarding. Everything checked out. The relationship had been running for two years without issue.
In month seven of year three, a fraudster — having mapped the supplier relationship through LinkedIn and the company's own website — submitted a bank change request by email. The email came from a domain one character different from the real contractor's. The AP team updated the vendor master file. No re-verification check was run. The next quarterly payment of £85,000 cleared to the fraudster's account.
The real contractor followed up six weeks later about an overdue invoice. By the time the company's bank was contacted, the funds were gone. Total loss: £85,000. Recovery: zero. The onboarding verification had been clean. The problem was the eight months of silence between that check and the fraudulent account change — and the absence of any monitoring during that window.
The verification was not the failure. The absence of monitoring was. A continuous monitoring check run at any point in those eight months would have returned a clean result — because the account hadn't changed yet. A check run after the fraudulent update would have flagged the ownership mismatch before the payment ran. The fraud window was the gap between verification and the next scheduled check. That gap was eight months. It should have been thirty days.
What changes in a vendor account should concern you
Not all changes carry the same risk — and bank account changes are only one part of the picture. A supplier can change in ways that have nothing to do with their account number and still represent a serious risk to your payments. Effective monitoring covers both layers: the banking data and the company data behind it.
MonitorPay monitors both. Here is the full set of changes that should be on your radar.
Banking changes
| Change type | Risk level | Why it matters | Response |
|---|---|---|---|
| Account number change | 🔴 Critical | Most common fraud vector. The destination of your payment has changed entirely. | Hold all payments. Re-verify via out-of-band call to known contact. Do not use details from the change request. |
| Sort code / routing number change | 🔴 Critical | Often accompanies account number change. May indicate a bank switch — legitimate or fraudulent. | Hold all payments. Re-verify ownership before next payment run. |
| Account ownership mismatch | 🔴 Critical | The account exists but no longer belongs to the legal entity on your vendor record. Classic fraud signal. | Do not pay. Escalate immediately. Treat as a confirmed fraud attempt until proven otherwise. |
| Account status change (closed / dormant) | 🟠 High | A closed account means your payment will bounce or be misdirected. A dormant account may indicate the supplier has changed banking. | Pause payment. Contact supplier via known channel to obtain updated details. |
| Name mismatch | 🟠 High | Account is active but the registered name no longer matches your vendor record. Could be a legitimate rebrand or a fraud indicator. | Do not pay until mismatch is resolved. Request written confirmation from supplier on company letterhead. |
| Bank change only (same account number, new IBAN/SWIFT) | 🟡 Medium | Supplier has moved bank but retained account. Verify ownership still checks out at the new institution. | Re-verify ownership at new bank before next payment. |
Company-level changes
The company behind the bank account can change independently of the account itself. These signals often arrive before a fraud attempt is made — or flag a deteriorating supplier that represents a different kind of payment risk.
| Change type | Risk level | Why it matters | Response |
|---|---|---|---|
| Legal name change | 🔴 Critical | A company rename may be legitimate — or it may signal a restructuring designed to obscure liability, ownership, or fraud history. Any name change should trigger re-verification of the bank account against the new legal entity. | Re-verify account ownership under the new legal name. Update vendor master file only after verification passes. |
| Ownership change / UBO change | 🔴 Critical | A change in beneficial ownership can alter your exposure to sanctions, PEP risk, or reputational harm overnight — even if the company name and account number stay the same. Required disclosure under KYB frameworks in most jurisdictions. | Trigger a full KYB re-screen. Check new UBO against sanctions and PEP lists. Escalate to compliance if new owner is flagged. |
| Sanctions hit | 🔴 Critical | A supplier added to OFAC, EU, UN, or UKFT sanctions lists after onboarding creates immediate legal exposure for any subsequent payment — regardless of when they were cleared at onboarding. | Freeze all pending payments immediately. Notify compliance and legal. Do not process until cleared. Retain evidence of the alert for regulatory purposes. |
| Legal status change (dissolution, striking off, insolvency) | 🔴 Critical | Paying a dissolved or insolvent entity creates both financial risk (funds may be unrecoverable) and legal risk (payments to insolvent companies may constitute a preference payment). | Hold all payments. Confirm status via company registry. Engage legal counsel before any payment is released. |
| Legal form change (e.g. Ltd to PLC, sole trader to Ltd) | 🟠 High | A change in corporate structure may mean the legal entity you contracted with no longer exists in its original form. The liability profile, tax status, and payment terms may all change. | Review contract validity under the new legal form. Re-verify bank account ownership under the new entity registration. |
| Court judgement / CCJ | 🟠 High | A county court judgement or equivalent indicates the supplier is failing to pay its own debts. This is a leading indicator of cash flow distress and potential insolvency — and a signal that payments you make may not result in services delivered. | Review payment terms and contract exposure. Consider requiring performance bonds or staged payments. |
| Credit score deterioration | 🟠 High | A significant drop in credit score — particularly a multi-notch downgrade — signals financial distress. Suppliers under financial pressure are both higher fraud risk (desperate actors) and higher operational risk (inability to deliver). | Review payment exposure. Consider reducing payment terms or requiring upfront delivery confirmation before payment. |
| Trade payment data deterioration | 🟡 Medium | A supplier that begins paying its own creditors late is under cash pressure. This is an earlier signal than a credit score drop — trade payment data often moves first. | Monitor closely. Flag for quarterly review. Consider reducing outstanding payment exposure. |
| Registered address change | 🟡 Medium | An address change is often routine. But a change to a registered agent address, a PO box, or an address associated with known shell company activity is a red flag — especially when combined with other changes. | Verify the change is legitimate. Cross-reference the new address against your other vendor records for shared-address anomalies. |
| Director / officer change | 🟡 Medium | A significant change in leadership — particularly multiple director resignations in a short window — can precede insolvency, restructuring, or fraud. It also changes who is authorised to instruct payments on the supplier's behalf. | Update authorised contact records. Consider re-verifying identity of new contacts before processing any bank change requests they submit. |
Bank account changes and company-level changes often arrive together. A supplier that has been dissolved, restructured, or acquired frequently submits a bank change request around the same time. Monitoring both layers means you catch the combination — which is far harder to explain away as coincidence than either signal in isolation. MonitorPay's continuous monitoring covers both banking data and company-level registry signals, so a single alert can flag multiple concurrent changes on the same vendor record.
Risk level distribution — all monitored change types
16 change signals across banking and company data, ranked by risk tier
The most dangerous changes are the ones that look legitimate on the surface — an email from the supplier's correct domain, a PDF on what appears to be company letterhead, a phone call from someone who knows the right invoice references. None of these confirm that the account itself belongs to the right entity, or that the entity behind it has not fundamentally changed. Only independent monitoring of both layers does that.
The alternative: continuous monitoring as a substitute for push notification
Since banks will not notify you, the only viable approach is to build your own notification system — not by waiting for a change request to arrive, but by proactively re-checking account ownership on a schedule you control.
This is what continuous vendor bank account monitoring means in practice. It is not a live feed of changes. It is a systematic, scheduled re-verification of the accounts in your vendor master file, designed to catch any discrepancy between what is on record and what the account currently shows.
When a check returns a mismatch — the account no longer belongs to the entity in your records, or the account has closed, or the name no longer matches — that is your notification. Not a push from the bank, but a pull from your own monitoring cadence. The practical effect is the same: you know something has changed before a payment goes out.
Verification vs monitoring — what each one does
These two controls are often confused. They address different moments in the payment lifecycle and neither replaces the other.
| Bank account verification | Bank account monitoring | |
|---|---|---|
| When it runs | At onboarding and on any bank change request | On a scheduled cadence between payment events |
| What it answers | "Does this account belong to this supplier right now?" | "Has anything changed since we last verified?" |
| What it catches | Fraudulent accounts at the point of submission | Account changes that occur after initial verification |
| Trigger | Event-driven — onboarding, change request, large payment | Time-driven — weekly, monthly, or quarterly cadence |
| Audit output | Single check result, timestamped | Ongoing log of checks, mismatches, and alert history |
| Nacha 2026 obligation | Satisfies first-payment and account-change verification | Satisfies ongoing risk-based monitoring requirement |
Monitoring is a proxy, not a replacement. If a supplier changes their account on Monday and your next scheduled check runs on Friday, you have a four-day window where a payment could go to the wrong account. The tighter your monitoring cadence on high-value suppliers, the smaller that window. For suppliers you pay weekly, daily checks are appropriate. For quarterly suppliers, monthly checks close the gap adequately.
This also directly satisfies Nacha 2026's ongoing monitoring requirement. The rules require documented, risk-based processes for identifying potentially fraudulent ACH activity — not just at onboarding, but as an ongoing obligation. A continuous monitoring programme with a documented cadence, logged check results, and a defined escalation process is exactly what "risk-based monitoring" means in practice. It is auditable, repeatable, and scalable in a way that manual callbacks are not. If you are building this for the first time, our guide to vendor bank account verification covers the onboarding layer that monitoring sits on top of.
How to set a vendor monitoring cadence that actually works
Monitoring every supplier daily is not practical at scale, and it is not necessary. The right cadence is risk-based — calibrated to payment frequency, transaction value, and the supplier's change history. Here is a framework that works for most AP teams.
Two events should always trigger an out-of-cycle check, regardless of where a supplier sits on your cadence schedule:
- Any incoming bank change request — email, phone call, portal submission, or letter. Before you update the vendor master file, re-verify ownership of the new account independently. See our vendor onboarding and management guide for the full bank detail change protocol.
- Any payment over your high-value threshold — even if the last scheduled check was clean, run a fresh ownership check before releasing a payment that materially exceeds your normal run with that supplier.
The logic is simple. Scheduled monitoring catches changes that happen between payment runs. Triggered monitoring catches fraud that is timed to coincide with a large payment. Both are necessary. Neither alone is sufficient.
What a mismatch alert should trigger in your AP workflow
A mismatch is not a problem to investigate later. It is a payment hold, effective immediately. The workflow that follows a mismatch alert should be documented, trained, and consistent — because the moment of a mismatch is exactly when social engineering pressure tends to escalate.
-
1
Hold all pending payments to this supplier Immediately flag the vendor record in your ERP or AP system. No payment should be released until the mismatch is resolved. This includes payments already in the approval queue.
-
2
Contact the supplier using details already in your system Do not use any contact information from the change request or any recent email. Use the phone number and email address from your vendor master file as it existed before the mismatch. Call — do not email.
-
3
Ask the supplier to confirm whether they initiated a change Keep the question open. Do not tell them what account number you have on file or what account number appeared in the mismatch. Let them confirm unprompted. If they did not initiate a change, you have confirmed fraud.
-
4
If the change is legitimate, re-verify ownership of the new account Ask the supplier to submit updated bank details through your secure vendor portal. Run a fresh account ownership verification check on the new account before updating the vendor master file. Do not rely on a voided cheque or PDF — these can be forged.
-
5
If the change is fraudulent, preserve evidence and report Do not update the vendor record. Preserve the original change request, any associated emails or call logs, and the mismatch alert output. Report to your fraud team, your bank's fraud line, and the relevant authority (Action Fraud in the UK, IC3 in the US). Notify your cyber insurer.
-
6
Log the event and update your monitoring cadence Every mismatch — whether fraud or a legitimate change — should be logged with timestamp, resolution outcome, and the person who authorised the update. Move the supplier to a higher monitoring tier for the next 90 days regardless of outcome.
Expect pressure. The most sophisticated fraud attempts are timed to coincide with end-of-month payment runs, just before a supplier's payment due date, or when your usual AP contact is on leave. If anyone — internal or external — pushes you to release a payment before a mismatch is resolved, that is a red flag, not a reason to proceed. The documented workflow is your protection.
The vendor master file problem — and why it matters for monitoring
Monitoring individual accounts is straightforward once you know which accounts to monitor. The harder problem — and the one most enterprises ignore — is the state of the vendor master file itself.
The average enterprise vendor master file contains years of accumulated data: suppliers onboarded under old processes, accounts that were never verified, banking details last updated by email in 2019, and dormant vendor records that nobody has reviewed since the person who set them up left the company. According to Trustpair's 2026 fraud report, only 32% of organisations validate vendor bank accounts continuously — which means 68% are paying against records of unknown integrity.
Before you can monitor effectively, you need to know what you are monitoring. That means a vendor master file audit: identify every active vendor, confirm which have been verified and when, flag records with banking details older than 12 months, and deactivate vendors with no payment activity in the past 18–24 months. This is not a one-time project — it is the baseline from which monitoring operates.
A practical audit test. Pull the last 20 vendor bank account changes from your ERP. For each one: was an ownership verification check run before the update was made? Was the change approved by someone other than the person who received the request? Is there a call log or portal submission on file? If you cannot answer yes to all three for most of those changes, your vendor master file has gaps that monitoring alone will not close. Start with the vendor onboarding and management guide to set the baseline, then layer monitoring on top.
Prioritising which vendors to monitor first is also a master file exercise. Sort your active vendor list by annual payment volume, payment frequency, and time since last verification. The vendors at the top of that list — highest value, most frequently paid, longest since last check — are your immediate monitoring priority. Work down from there based on your available cadence budget.
How MonitorPay's continuous monitoring works
MonitorPay's Continuous Monitoring is built on the same account ownership verification infrastructure used for onboarding checks — the difference is cadence and alerting.
Once a supplier is added to monitoring, MonitorPay runs scheduled ownership checks against their verified account details at the frequency you configure. If the check returns the same result as the verified baseline — account active, ownership confirmed, name matches — no alert is generated. If anything changes — account closed, ownership mismatch, name change, account status flagged — an alert fires to your configured recipients before your next payment run.
The checks run against government and banking registry data in 190+ countries, using the same first-party data sources that underpin our Account Ownership Verification and Payee Name Verification products. There is no ERP dependency and no manual process — the monitoring runs automatically, and alerts are delivered via your configured channel (email, webhook, or API).
| Feature | How MonitorPay handles it |
|---|---|
| Monitoring cadence | Configurable per supplier — daily, weekly, or monthly |
| Alert trigger | Any deviation from verified baseline: ownership mismatch, closed account, name change, status flag |
| Geographic coverage | 190+ countries, including IBAN (EU/UK), ACH routing (US), BSB (Australia), IFSC (India) and more |
| Data source | Government and banking registry data — not self-reported, not crowd-sourced |
| Integration | REST API or bulk upload — no ERP dependency required |
| Audit trail | Every check logged with timestamp, result, and alert status — ready for Nacha, internal audit, or insurer review |
| Alert delivery | Email notification, webhook, or API poll — configurable per team |
For teams building toward Nacha 2026 compliance, the monitoring log also serves as the audit documentation the rules require — a time-stamped record of ongoing, risk-based checks that demonstrates your monitoring programme is live, documented, and reviewed. Our Continuous Monitoring product page covers setup and integration in detail.
Frequently asked questions
No. Banks have a relationship with their own account holders, not with the businesses that send payments to those accounts. When a supplier changes their account details, their bank notifies them — not you. There is no commercial banking product in any major market that offers a payer a push notification for changes to a payee's account. The only way to know whether a supplier's account details have changed is to check them yourself on a schedule you control.
Continuous vendor bank account monitoring is the practice of running scheduled, automated ownership verification checks against your vendor master file on an ongoing basis — not just at onboarding. Each check confirms that the account on your record still belongs to the legal entity it is assigned to, is active, and matches the name on your records. If anything deviates from the verified baseline, an alert fires before your next payment run. It is the practical substitute for real-time bank notification, which does not exist.
The cadence should match your payment frequency and transaction risk. A practical framework: weekly or before every payment for high-value or frequently paid suppliers; monthly for mid-value recurring relationships; quarterly for low-frequency, low-value suppliers. Two events should always trigger an out-of-cycle check regardless of tier: any incoming bank change request from the supplier, and any payment that materially exceeds your normal transaction size with that vendor.
Verification is a one-time or event-triggered check: you confirm that a bank account belongs to the entity on your record at a specific point in time. Monitoring is an ongoing programme of repeated verification checks designed to detect changes that occur after initial verification. Verification answers "is this account legitimate right now?" Monitoring answers "has anything changed since we last checked?" Both are necessary — verification at onboarding and on any bank change request, monitoring between those events.
Yes. Nacha's 2026 rules require all non-consumer ACH Originators to establish and implement risk-based processes to identify potentially fraudulent ACH entries on an ongoing basis — not just at first payment. The rules specifically address payments made under False Pretenses, which includes vendor impersonation and bank account substitution fraud. A continuous monitoring programme with documented cadences, logged check results, and a defined escalation process is the mechanism that satisfies this ongoing obligation. A one-time onboarding check alone does not meet the monitoring requirement.
Immediately hold all pending payments to that supplier. Contact the supplier using the phone number already on your vendor record — not from any recent change request or email. Ask them to confirm whether they have initiated a bank change. If they confirm the change is legitimate, ask them to submit new details through your secure vendor portal and run a fresh ownership verification check before updating the vendor master file. If they have not initiated a change, you have identified a fraud attempt — preserve the evidence, report to your bank's fraud line, and file with Action Fraud (UK) or IC3 (US).
No. Open banking frameworks like PSD2 allow a business to grant a third party access to their own account data. They do not allow a payer to access notification data for a payee's account. The data sharing under open banking is always account-holder-initiated — your supplier would have to explicitly grant you access to their account change data, which no supplier does in a commercial relationship. Open banking does not close the notification gap. Continuous monitoring remains the only practical approach.
That depends entirely on your monitoring cadence. If a supplier's account is compromised on Monday and your next check runs on Friday, four days of payments are at risk. If you pay that supplier weekly, that could be one full payment run. This is why high-value and frequently paid suppliers should be checked weekly or before every payment. The 277-day average fraud detection time reported by IBM reflects organisations with no ongoing monitoring — organisations with active monitoring cadences catch mismatches within days, not months.
The risk-based cadence applies globally, but international suppliers carry additional risk factors that may warrant a higher monitoring frequency — currency exposure, longer payment transit times, fewer real-time fraud detection mechanisms, and less mature open banking infrastructure that makes out-of-band verification harder. For cross-border payments, consider defaulting to monthly monitoring regardless of transaction value, and always run a fresh ownership check before any international wire above your risk threshold. MonitorPay's continuous monitoring covers 190+ countries using the same government and banking registry data sources for all markets.
No. Confirmation of Payee is a name-matching service run at the point of payment initiation in UK Faster Payments — it checks whether the account name matches the sort code and account number you are about to pay. It runs once, at payment time, and it only works within the UK Faster Payments network. Continuous monitoring is an independent, scheduled programme that checks account ownership against your vendor master file across any payment rail and any country, at a cadence you control — and it runs between payments, not just at payment time. They address different moments in the payment workflow and should be used together, not instead of each other.
