Bank Change Requests

Open this screen in Saral/hr/bank-change-requests

A change to the account a worker is paid into is the one edit a fraudster wants most, so it never lands silently. Every request — from the worker's portal or typed by the office — sits here with the fraud risk Saral scored, the machine check against the worker's bank document, what is on file now, and whether the worker has confirmed it was them. Finance approves or rejects; nothing is changed on the record, and no payment file uses the new account, until then.

You enter

Approve or Reject on a pending request, a reason for a rejection, and the explicit Approve despite risk on one flagged high risk.
A change the office makes itself is raised on the worker's Bank card, not here — it arrives in this queue as Awaiting worker until the worker confirms.

Saral fills in

The requested sort code and account number beside what is on file, masked, with Show to compare the full digits — and a server-side verdict on whether they are really a different account even when the last four digits match.
The fraud risk — low, medium or high — with its reasons: the account already on file for another worker in the group, a holder name that does not match the worker, a sort code and account number that fail the bank check, repeated changes in 90 days, or both numbers changed at once.
The Saral machine check for a worker's own portal change: the typed details against the bank document they uploaded, and whether the account is in their name.
Whether the worker was asked to confirm, when, and what they answered — including This wasn't me, which is shown in red and never changed back silently.

It produces

The approved account on the worker's record, used by the next payment file; a rejected request with its reason, kept.
A verification request's answer — are these still yours — with nothing changed either way.
An audit row for every decision, and the history the next request is compared against.

What this page is for

Payment diversion fraud is an email that says please pay me into this account from now on. The defence is that no change to the account a worker is paid into reaches a bank file without a second look: the request waits here, Saral says how risky it looks and whether the document behind it agrees, the worker is asked whether it was them, and Finance decides. The record is untouched until approval, so a request in this queue cannot be paid to by any file made meanwhile.

Where a request comes from

A worker changes their own details in their portal: Saral runs the machine check — the typed sort code, account number and account holder against the bank document they upload — and a change that passes, in their own name, is applied with the machine's reasons shown here as information. One that fails waits on the worker for a better document, with Saral having told them what was wrong; an account not in their name carries their reason for the office to weigh. A change the office types on the worker's Bank card is staged as Awaiting worker and emailed to the worker; it is applied when they confirm, or by the office with a written override reason. A verification request — are these still yours — compares nothing and changes nothing: it is a check, not a change.

Reading the risk

Every pending change carries a risk the server scored from the facts it holds: whether the requested account is already on file for another worker in the group (the strongest signal), whether the account-holder name matches the worker or their company, whether the sort code and account number pass the bank's modulus check, how many changes this worker has made in the last 90 days, and whether both numbers changed at once. The reasons are listed under the card. High risk does not refuse — it asks for a second, explicit Approve despite risk — because a frozen payment is not a safer failure than a flagged one. The masks on screen never decide anything: the comparison of full digits is done server-side and printed as a sentence under the two accounts.

After the decision

An approved account is on the worker's record at once and the next payment file prints it. A rejection keeps the request and its reason. A worker who answers the confirmation email with This wasn't me is shown in red on the request, nothing is changed back on its own and payments are not held — the office checks it before the next file and restores the right account from the Bank card. Every decision writes an audit row, and the account a reasoned clear removed stays in the history the next request is compared with.

Where the settings live

Whether new or changed bank details wait for an admin before they are used is on HR → Settings → Onboarding (Admin approval of bank details). The bank document a starter must upload and the machine check on it are on the same tab. Whether someone else must confirm a bank-detail change during a worker's separation is on HR → Settings → Approvals & controls. The worker's current account is on their record's Bank card, and the payment files that print it are Payment Batch and Invoices – non-CIS.

Next screen: /hr/reports

Not what you needed? Inside Saral, ask Kuku (Alt+K) — if it cannot answer, “Ask a human” sends the question to Saral support with the chat attached.