Home · Solutions · Other solutions
Solution · Other solutionsA change of salary account that nobody can request on somebody else's behalf
Employees change their own address, name and bank details
Employees edit their own address, name and bank details from an authenticated card in Microsoft Teams; every bank change passes a confirmation and a payroll call-back before a robot writes it.
Executive summary
A three-line e‑mail should not be able to move somebody's salary to a different account.
We build the change itself, not a form that generates an e‑mail.
Diverting a salary stops being a matter of writing a convincing e‑mail, because the change needs the employee's own sign-in.
the SAP SuccessFactors or Workday master record; the payroll system; contact attributes in Microsoft Entra ID
Business problem
HR self-service
Personal data changes arrive as e‑mail and paper, and each one is retyped by HR or payroll into the systems that hold it. The work looks trivial, which is why it has never been redesigned. Bank changes are the dangerous ones: a forwarded message carries no proof of who wrote it, and the person keying it is usually working against a cut-off.
Around that risk sits an everyday cost. The same values are entered twice, into two systems with different field rules, so an address that is right in the HRIS is wrong in payroll and official letters go to a flat somebody left in March. A name change touches four systems and is rarely completed in all of them on the same day.
The problem persists because the volume is steady rather than dramatic. HRIS self-service is switched off for bank data on security grounds, which leaves the manual route as the control. It is not a control. It is the gap, and the only thing standing in it is one administrator's caution on a day when she has forty other things to finish.
How it works today
The route below is recognisable in most companies where the payroll team is smaller than the store network.
- PersonAn employee sends a change by e‑mail or hands a paper form to a store manager
- PersonThe manager forwards it to HR or payroll with a line asking for it to be processed
- SystemAn administrator reads the message and keys the new values into the HRIS
- SystemThe same values are keyed a second time into payroll, and sometimes into the directory
- WaitingA confirmation goes back to the employee only if somebody remembers, often after the cut-off has passed
- Risk of errorNo verification step exists that does not depend on one person's caution on a busy day
- Risk of errorThe error surfaces on payday or as returned post, and is closed with a correction and an off-cycle payment
Why the current process costs more than it appears
The cost grows where nobody is looking.
- Fraudulent bank-change requests are indistinguishable from genuine ones inside a mailbox, and they are timed for exactly the week in which payroll is busiest.
- One diverted salary is not one cost. It is a month of net pay, a police report, a recovery attempt that usually fails, an employee without money and a conversation nobody in HR wants to have.
- Double entry generates its own error rate: two systems, two sets of field rules, one pair of hands, and the returned post that follows.
- Auditors ask how bank changes are verified. The honest answer describes what a careful administrator does, not what the process guarantees, and those are two different documents.
- Corrections are paid for after the event. An off-cycle run carries a bank fee, an hour of payroll time and an apology, and it happens roughly thirty times a month at this volume.
Cost of inaction
Turnover holds the volume steady, so twelve months on this route means several thousand changes handled by e‑mail with no verification step that survives a busy day, and the probability of one diverted salary is a function of that count rather than of anyone's diligence. Each correction costs an hour, a bank fee and an apology, and every one of them is a conversation with somebody whose rent was late.
An auditor asks the verification question once a year and receives a process description that does not match practice. The exposure the rows above cannot carry is the one that ends the argument: a month of net pay paid to a stranger, a police report, a recovery attempt that usually fails, and a board that wants to know why an e‑mail was enough.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A retail chain with 4,600 employees across 190 stores, high staff turnover and a payroll team of five; SAP SuccessFactors Employee Central holds the master record and payroll runs in-house.
Around 620 personal-data changes a month, roughly half of them addresses and a quarter bank details, arriving mostly as e‑mails forwarded by store managers.
Changes are read from a mailbox, keyed into the HRIS and keyed again into payroll. An attempted bank-detail fraud last year was stopped only because an administrator happened to telephone the employee before the run.
Fifteen minutes of handling per change across HR and payroll, plus about 31 corrections a month at 45 minutes each; the verification step appears in nobody's process description.
The employee edits their own record from an authenticated card in Microsoft Teams, or a Power Apps form on a store device; address and contact changes post straight through, and every bank change passes a confirmation to the identity already on record plus a payroll call-back before a robot writes it.
In the modelled case double entry disappears, corrections fall because format rules stop errors at input, and verification becomes a queue with evidence instead of a phone call somebody may remember making. Illustrative, not a client result.
Proposed solution
We build the change itself, not a form that generates an e‑mail. The employee opens a card in Microsoft Teams, signed in with their Microsoft Entra ID account, and sees the data the HRIS currently holds about them. Store staff without a desk use the same thing as a Power Apps form on a shared device or a phone. Editing is constrained by rules rather than by hope: the IBAN checksum is validated, the address is checked against a structure, and a name change will not submit without the supporting document attached.
What happens next depends on what changed. Address, contact and emergency-contact changes are written straight through by a UiPath Robot, into the HRIS, into payroll and into the directory attributes, and confirmed in the same conversation. A bank change starts a control we design with finance and internal audit: a confirmation goes to the identity and the e‑mail already on record, never to anything supplied with the request, and a payroll verification task appears in UiPath Action Center with a call-back to the telephone number on file. The verifier is never the requester, and the task cannot be closed without recording what was checked.
Only when both confirmations are in does the robot post the change. It applies the payroll cut-off calendar, so the employee is told which pay run the new account will be used for, and it writes the before and after values into the Orchestrator audit record. A refused confirmation or an unanswered call-back holds the change rather than half-applying it, and both the employee and the payroll manager can see that it is held and why.
Microsoft Teams Adaptive Cards; Microsoft Power Apps forms for shared store devices; Microsoft Entra ID sign-in and group membership; UiPath Action Center tasks and actionable notifications in Microsoft Teams and Outlook; UiPath Orchestrator audit log
The self-service card and store form, the field and format rule set, the bank-change verification flow with its call-back evidence, the posting robot with cut-off logic, the held-change queue and the Power BI control view
Master-record reads and writes to SAP SuccessFactors through SAP OData or to Workday through the UiPath Integration Service connector; posting to the payroll system through its interface, or through UiPath SAP automation where no API is exposed
How the automated process works
- PersonThe employee signs in with Microsoft Entra ID and edits their own record from a card in Microsoft Teams
- AutomationFormat rules check the IBAN checksum, the address structure and the document a name change requires
- AutomationAddress and contact changes go straight to the robot, which writes the HRIS, payroll and the directory
- SystemA bank change sends a confirmation to the identity and e‑mail already on record, never to the new one
- PersonPayroll completes a verification task with a call-back to the number on file, and is never the requester
- AutomationWith both confirmations in, the robot posts the change and applies the payroll cut-off calendar
- AutomationThe employee is told which pay run it affects, and Orchestrator keeps the before and after values
Human-in-the-loop model
Automation handles
- Authenticated intake, so every request carries the identity of the person it belongs to
- Format and plausibility rules on IBAN, address, tax and contact fields before anything is submitted
- Confirmation requests routed only to contact details already on record
- Writing the verified change to the HRIS, payroll and directory, with cut-off logic and a confirmation
People decide
- Payroll verifies every bank change and records what the call-back established
- HR reviews the supporting documents behind a name change
- Held changes: a refused confirmation, an unanswered call-back, a leaver, a court-ordered deduction
- Which fields may ever be self-served, and which stay with HR
Before and after
Systems and integrations
Everything below runs on licences and systems you already hold, or would need anyway.
Inputs
- the self-service card in Microsoft Teams
- a Power Apps form on shared store devices
- the document upload behind a name change
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- the SAP SuccessFactors or Workday master record
- the payroll system
- contact attributes in Microsoft Entra ID
- the Power BI control view
Human touchpoints: the payroll verification task in Microsoft Teams; the confirmation sent to the identity on record; HR review of name-change documents
Technologies used
the authenticated card where an employee sees and edits their own record
Athe same request as a form on a shared store device or a phone
Athe sign-in that proves who is asking and the group that decides who may verify
Awrite the verified change to every system, apply cut-off logic, keep before and after values
Athe confirmation to the employee and the payroll verification task, completed in Teams or Outlook
Areads the current record and writes changes through APIs rather than screens
Aposts to payroll where no API is exposed
Athe control view: volumes by type and store, verification completion, held changes
AIllustrative economic model
A model, not a promise.
620 changes a month enter the calculator as 496, because one in five will still need a person and the automatable share is folded into the volume rather than applied to the result. Fifteen minutes is the combined handling across HR and payroll, the second keying included, and €31 is a fully loaded payroll administration rate. Corrections are priced separately under the table, and the fraud exposure is not priced at all. No client supplied any of these figures.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Diverting a salary stops being a matter of writing a convincing e‑mail, because the change needs the employee's own sign-in, a confirmation to their existing contact and a documented call-back
- Double entry disappears: one verified record is written to the HRIS, payroll and the directory by the same run
- Corrections and off-cycle payments fall because format rules stop the errors that cause them at the point of input
- Employees change their own data and learn which pay run it affects, which removes a whole category of payroll questions
- Payroll gains a verification queue with evidence instead of a phone call that may or may not have happened
- The control can be described to an auditor in one sentence and demonstrated from a log, not from a procedure document
The management view
- Payroll runs a queue rather than a mailbox, with every pending verification visible and ageing in one place
- HR sees volumes by change type and store, time to completion and the share needing human attention, which shows where a store is coaching employees to send e‑mails
- The CFO gets a control that survives an audit question without a rehearsal, because the evidence is generated by the process rather than assembled afterwards
- Every change carries requester, verifier, timestamp and before and after values, so a dispute is answered from the record instead of from a mailbox search
Board-level KPIs
Security and governance
Security is designed with the process, not after it.
- Identity is the control, not a step inside it: every request is bound to a Microsoft Entra ID sign-in, and confirmations are sent only to contact details that were already on record before the request arrived
- Segregation of duties is enforced rather than encouraged; the verifier cannot be the requester, and the group that may verify is a directory group, not a habit
- Bank details are masked in cards, notifications and logs, and the robot's service account holds write rights to the fields it changes and nothing else, with its password in a credential store the workflow never exposes
- Robots run in the EU region of UiPath Automation Cloud, cards and uploads stay inside your Microsoft 365 tenant under the EU Data Boundary, and Purview retention applies to name-change documents
- Orchestrator keeps before and after values for every field, so "what did this record say in March" has an answer that does not depend on memory
Why now
Social-engineering messages are now good enough that "it looked genuine" no longer satisfies an auditor, and payroll diversion has moved from a curiosity to a named fraud pattern with its own control expectations
Every employee already carries a Microsoft Entra ID identity and uses Microsoft Teams, which hands HR a channel that proves who is asking without anything new being bought
The money runs in the meantime: €3,844 a month of handling and €713 a month of corrections, none of which buys a single verified bank change
Relevant executive roles
An evidenced control against salary diversion that an auditor can test, rather than a description of what careful people usually do
Employees own their own data, and HR stops being the typing pool between a mailbox and two systems
Fewer corrections, fewer returned letters and one record that agrees with itself across systems
Verification becomes a logged queue with a call-back recorded against it instead of a phone call somebody thinks they made
Common questions and objections
Today anyone who can send an e‑mail can request the change. Here it needs the employee's own sign-in, a confirmation to the contact details already on record and a call-back that payroll has to document before the posting runs.
Then the robot delivers the verified change to the provider's portal or file interface, with exactly the same control in front of it. Outsourcing moves the keying, not the verification question.
The form runs on the store device or on a phone, and the sign-in is the one they already use for their shift. Anyone who can read a rota in Microsoft Teams can change their own address.
When this is not the right solution
- HRIS self-service already handles these fields and payroll trusts the verification step in front of it
- Employees have no Microsoft 365 identity, which removes the only thing that makes this a control rather than a faster form
- A payroll migration is already scheduled, in which case the control is designed now and built into the new system rather than twice
A question for the next management meeting
Which control in this company stands between a forwarded e‑mail and a changed salary account, and where is the evidence that it was applied last month?
Implementation approach
The first week looks the same at every client: we look at the data.
We deliver
- The bank-change control designed with finance and internal audit, written down as something that can be tested
- The self-service card in Microsoft Teams and the Power Apps form for shared store devices
- The field, format and plausibility rules, including IBAN validation and the document requirement for name changes
- The posting robot for the HRIS, payroll and directory, with the payroll cut-off calendar built in
- The verification queue, the held-change route and the notifications that go with both
- The Power BI control view, training for payroll and hypercare through the first full pay cycle
We need from you
- The list of fields employees may change, and which system is the source for each of them
- API access to the HRIS and the payroll interface, plus a test tenant with representative records
- A payroll verifier and an owner for the control on the finance side
- The payroll cut-off calendar and the current correction volumes
Stages
Discovery
Fields, systems, cut-off calendar and the verification control agreed with finance and audit
Design
Card and form, rule set, confirmation and call-back flow, security model, held-change handling
Build
Rules, posting robot, verification tasks and control reporting in your own tenant
Pilot
Address changes in one region, then bank changes for one pay cycle under payroll supervision
Rollout
Name changes with document review, the store form and the remaining regions, with hypercare
Quick win. Effort is driven by how many systems hold the same field, whether payroll exposes an interface or only a screen, and how much of the verification control has to be agreed with audit before anything is built.
The e‑mail that moves a salary to a new account is three lines long.
Give us last quarter's bank-detail requests with the names removed. We return the ones our control would have held for verification, with the reason attached to each.
Test last quarter's bank changesThe neighbouring process usually has the same problem
Payroll errors are found by the employee on payday, not by the team that built the file.
View solution Finance & accountingVendor master changes with bank-account fraud controlOne convincing email is all it takes to send a six-figure payment to a fraudster's account.
View solution Other solutionsTimesheets complete before the payroll cut-off, every monthTwo specialists spend the end of every month writing reminders, and payroll still pays on estimated hours.
View solution Other solutionsNo payment to a vendor nobody verifiedA bank account changed because an email asked is the cheapest way to lose a six-figure payment.
View solution Case studyEmployee data mass updateHundreds of data changes done quickly, safely and error-free.
View case study Case studyThe HR agent on TeamsAn employee asks on Teams about leave, a certificate or a benefit.
View case studyIndustries we deliver this in most oftenManufacturing & industryRetail & e‑commercePublic sectorServices & ITShared services