Why this change is different
Most changes to a vendor record are housekeeping: an address, a contact, a tax form. A change to bank details is different in kind, because it decides where the next payment goes. The request often arrives by email, looks routine, and reaches someone with a queue to clear.
ERP systems record the change and usually support an approval step. The weakness is that the change is often treated as master-data maintenance, reviewed for completeness, while the money risk appears later, in a payment run that sees nothing unusual about a valid vendor with valid details.
Where the check sits
The check belongs between whatever proposes the change and the ERP write. The proposer may be a clerk using a form, an integration from a vendor portal, or an automated assistant working through an inbox. In each case the proposal is the same: change these details for this vendor.
The same check belongs in a second place: before a payment run releases money to an account that was changed recently. The first check asks whether the change is authorized and verified. The second asks whether enough has happened since the change to trust it with a payment.
What the check can require
The rules are familiar to anyone who has worked in accounts payable. What changes is that they are enforced in the path, before the write, instead of being reviewed afterwards.
- The requester has authority to change vendor bank details at all.
- The change was confirmed through a channel other than the one that requested it, and a named person recorded that confirmation.
- The person who made the change cannot be the one who releases the next payment to that vendor.
- The first payment to a changed account is held for a set period, or above a set amount, until a reviewer approves it.
- When evidence is missing, the action is escalated to a person and not silently applied.
What to keep as evidence
When a payment is questioned months later, the useful answer is specific: this change was proposed by this party, this policy version required a confirmation, this reviewer approved it at this time, and this is what the ERP answered. Records that are signed and linked to each other make gaps and edits visible, which is what gives the answer weight.
It helps to record what was refused or held as well as what went through. A control that only logs successes cannot show that it ever stopped anything.
Where StreamKernel is today
This is the same check StreamKernel demonstrates on payment transfers: a proposed action is evaluated against policy before anything is sent, with signed records before and after. For ERP actions it is pilot work. No ERP connector ships today, nothing ERP-specific exists in the runtime yet, and a control that spans two documents, the change and the later payment, is something a pilot would build.
That makes the practical starting point narrow on purpose: one action, such as bank-detail changes for one vendor group, with your rules and your reviewers, built and measured before anything wider.