Supplier bank changes in OpenText VIM: name who may clear the hold
Detection is not clearance
Public conversation around practical AI controls in the OpenText VIM space has included AI-assisted supplier banking change detection as an example of a useful flag—alongside extraction and coding suggestions. Treat that as product and webinar framing in the market, not as a McCloy metric and not as a fraud scare.
The operating choice is narrower: when a bank-detail mismatch or change is flagged on an invoice path, who may clear the hold, what evidence is required, whether dual control applies, and whether the durable fix is in the vendor master or only on the current document.
This is not a retread of AI extraction named owner. Extraction ownership is about field proposals and quality. Bank-change holds are about payment risk controls and master-data truth.
The operating choice
Write a one-page control that AP, vendor master, and SoD can all sign:
What triggers the hold. Mismatch to vendor master bank data; change vs last payment; high-risk country or amount bands if you use them—named as configured, not as folklore.
Who may clear. Named roles. Dual control where finance/SoD require it—proposer and approver are different people; shared inboxes do not count as two people.
What evidence is required. Vendor confirmation channel you trust; call-back rules; documents that must be attached; what is never enough (a PDF stamp alone, a forwarded email from an unverified address).
Vendor master vs invoice path. When the master must be updated before further payments; when a one-time invoice exception is allowed; who owns the master change ticket.
What the AI (or rule) flag is allowed to do. Flag and park—not silently “fix” bank data. Humans clear; systems propose.
Who carries it? AP process owner owns invoice-hold clearance procedure. Vendor master / procurement data steward owns durable bank data in the master. Finance owns payment-risk policy and dual-control requirements. Security/SoD confirms segregation. VIM functional lead configures the hold reason and routing. Capture/AI owner (if a model assists detection) owns false-positive review rhythm and not payment authority.
Dual control without theater
Dual control fails when:
The same person clears under two user IDs.
A shared AP inbox “approves” what a colleague parked.
Master data is updated after payment went out “to clear the queue.”
Evidence lives only in a personal mailbox.
Write the happy path and the fail-closed path. A hold that times out into payment is not a control.
Clean core reading
Keep bank-change controls in the VIM / SAP process and vendor-master processes you already run. Prefer published hold reasons and workflows over a parallel tracker outside the system. If AI assists detection, treat it as a signal into that control—not as a second payment system. Do not invent fraud-loss percentages. Do not weaken SoD because “the model looked confident.”
What this is not
This is not a fraud panic piece. It is not a mandate to turn on every AI feature this quarter. It is not a claim that detection eliminates supplier-bank risk. It is not competitor blame. It is not the same article as generic AI extraction ownership. Name the clear-hold authority and the master-data path.
A practical checklist
Hold reason inventory: bank mismatch / bank change—routing, SLA, fail-closed behavior.
Clearance RACI: who proposes, who approves, who updates vendor master, who may not.
Evidence standard: one page SoD and AP both accept.
Ten test cases: true change with good evidence; true change with bad evidence; false positive; dual-control break attempt; master updated vs invoice-only exception.
Monthly sample: five cleared holds—evidence present, dual control held, master state correct.
After release or AI-model changes: re-prove the hold still parks and still requires the same clearance path.
How the SOW should read
Prefer language like: “For supplier bank-change / bank-mismatch holds in OpenText VIM: document trigger, named clear-hold roles with dual control where required, evidence standard, vendor-master vs invoice-exception path; AI or rule flags may park but not silently change bank data; AP, vendor master, and SoD sign acceptance.” If the paper only says “enable bank-change detection,” require the clearance and master-data lines.
