In August 2020 Citibank, acting as administrative agent on a Revlon loan, meant to send lenders an interest payment of about eight million dollars and instead wired them roughly 900 million dollars of principal, the full amount of the loan, because of the way a manual override was keyed into a payment system. Some lenders kept the money. A district court said they could; the Second Circuit reversed in 2022 and the funds came back, but only after two years of litigation, an OCC enforcement action over risk management, and a permanent place in every payments-control training deck. That is the nine-figure mistake, and it was not fraud. It was an interface, a checkbox, and three people who each believed the other two had checked. The fraud side is larger and quieter: the FBI’s Internet Crime Complaint Center recorded 24,768 business email compromise complaints in 2025 with losses of 3.05 billion dollars, up from 2.77 billion in 2024, and its Recovery Asset Team froze 679 million of the 1.16 billion dollars it was asked to chase, a 58 percent success rate that depends entirely on the victim noticing within hours. The AFP’s 2026 Payments Fraud and Control Survey found 76 percent of US organisations experienced attempted or actual payments fraud in 2025, with cheques still the most targeted instrument (58 percent) and wires targeted at 25 percent.
This guide is the internal auditor’s version of the payment operations audit, written for both sides of the wire: the bank that operates a wire room and the corporate that operates a payment factory or a treasury desk. It covers the payment life cycle and where the risk concentrates, the legal frame that decides who bears a loss, a starter risk and control matrix, a fourteen-test program, the analytics that find the exposure before the loss, a worked engagement in Lakeshore Bancorp’s wire operations with every test’s result, the findings that recur with wording that lands, and scoping variants for a corporate payment factory, a small company on an online banking portal, and instant payments. It pairs with the treasury guide, which covers the function that owns the accounts, and the accounts payable guide, which covers the process that decides what gets paid.
In this guide
- Know the terrain: the payment life cycle and the rails it runs on
- Who bears the loss: the legal frame in one section
- The payments risk map
- The starter RCM: ten controls that carry the process
- The 14-test program
- The analytics that find the exposure before the loss
- Worked example: Lakeshore Bancorp’s wire operations audit
- The findings that recur, and wording that lands
- Scoping variants: payment factory, small company, instant payments
- Where to go next
Know the terrain: the payment life cycle and the rails it runs on
Every payment, whatever the rail, passes through the same eight stages, and the audit is organised around them: initiation (someone or something creates an instruction: a customer at a branch or on a portal, an ERP payment run, a treasury dealer, a fraudster with stolen credentials); authorisation (the instruction is approved under a delegation, ideally by someone other than the initiator, with limits by role and amount); verification (for new or changed beneficiaries and for out-of-pattern instructions, an independent call-back to a number on file); screening (sanctions and, for banks, anti-money-laundering rules run against the parties, with alerts dispositioned before release); release (the instruction leaves the organisation’s control, after which it can only be recalled by asking); transmission (the rail moves it: Fedwire or CHIPS for US dollar wires, SWIFT messaging for cross-border, ACH for batch, RTP or FedNow for instant, cheque and card for the rest); confirmation and exception handling (acknowledgements, rejects, returns, recalls, and the queue where the unusual sits); and reconciliation (what left the accounts against what the system thinks left, daily, by someone outside the payment team). Two facts about the rails matter for the audit. Wires are final and fast: once released and settled, a Fedwire payment is done, and recovery depends on the receiving bank’s willingness and the speed of the request, which is why the IC3’s kill-chain figures reward hours, not days. And the rails have been changing: Fedwire completed its migration to the ISO 20022 message format in July 2025, CHIPS moved in 2024, and instant payments through RTP and FedNow have grown since FedNow launched in 2023, which means richer data in the messages, new field-mapping errors, and irrevocable payments that settle in seconds at any hour.
Planning inputs worth an hour each: volumes and values by rail, channel and initiator type for the year; the payment system’s role design and user list against HR’s leavers list; the delegation of authority as configured in the system rather than as written; the exception queues (repairs, rejects, returns, recalls, sanctions alerts) with their aging; the fraud log, including attempts that were stopped, because the stopped ones tell you which control is working; the daily reconciliation and its unreconciled items; and the interfaces, meaning every path an instruction can take into the payment system, including the manual ones. Then sit in the wire room or the payment factory for a morning and watch a release cycle, a call-back and an exception being worked. Payment processes are visible in a way most processes are not, and the walkthrough will show you the shared login, the override nobody logs and the queue that gets emptied at four o’clock without being read.
Who bears the loss: the legal frame in one section
Auditors avoid the legal frame and it decides the money. For commercial wire transfers in the United States, Article 4A of the Uniform Commercial Code allocates the loss from an unauthorised payment order: if the bank and its customer agreed a security procedure that is commercially reasonable, and the bank accepted the order in good faith and in compliance with that procedure and the customer’s instructions, the customer bears the loss even though the order was fraudulent. That sentence is why banks insist on dual control, tokens and call-backs in their agreements, why corporates should read the agreement before they accept the procedure, and why the auditor’s first question in a payments engagement is whether the procedures the agreement describes are the procedures the company actually operates. Consumer transfers are governed differently (Regulation E in the US, with its error-resolution and liability limits), ACH transactions by the Nacha operating rules (including account validation for web-initiated debits), and cross-border wires by SWIFT’s contractual framework, under which banks and corporate members attest annually against the Customer Security Controls Framework, whose 2026 version carries 32 controls, 25 of them mandatory. Two consequences for the audit. A corporate that skips its own bank’s dual-control feature, or shares a token for convenience, has probably moved the loss from the bank to itself. And a bank whose security procedure exists in the agreement but not in the system has probably moved it back. Test the agreement against the configuration, not against the policy.
The payments risk map
| # | Risk | Where it lives | Error or fraud? |
|---|---|---|---|
| R1 | Business email compromise and beneficiary redirection: a genuine-looking instruction to pay a new account, or to change a supplier’s or customer’s bank details | Initiation, verification | Fraud (external, often with an insider’s mailbox) |
| R2 | Insider-initiated unauthorised payments: an employee with entry and approval rights, a shared credential, or an unrevoked leaver’s access | Authorisation, access model | Fraud |
| R3 | Fat-finger and mis-keyed payments: wrong amount, wrong beneficiary, duplicate release, the Revlon pattern | Initiation, release | Error |
| R4 | Sanctions and AML failures: payments released to sanctioned parties or without required screening; alerts closed without review | Screening | Compliance |
| R5 | Account takeover: customer or corporate credentials stolen, tokens intercepted, sessions hijacked; instructions look authorised | Channel security | Fraud |
| R6 | Exception-queue failures: rejects, returns and recalls not worked; funds parked in suspense; a recall request sent a day late | Confirmation and exception handling | Error; converts a recoverable fraud into a loss |
| R7 | Interface and message errors: ERP-to-bank files altered in transit or on a shared drive; ISO 20022 fields truncated or mis-mapped | Transmission | Both |
| R8 | Reconciliation gaps: payment system, core ledger and bank not reconciled daily; differences aged and written off | Reconciliation | Error; conceals R2 |
| R9 | Limits and cut-offs not enforced: per-transaction and daily limits configurable by the operations team; releases after cut-off handled manually | System configuration | Enabler of R2, R3 |
| R10 | Continuity: a payment system outage with no tested manual fallback, or a manual fallback with no controls | Operations | Error; fraud during fallback |
The starter RCM: ten controls that carry the process
| Ctrl | Control (condensed) | Type / frequency | Answers risk |
|---|---|---|---|
| C1 | Dual control is enforced in the payment system: entry and release by different users, with release limits by role and a second releaser above a value threshold; no user holds both roles and the configuration cannot be changed by operations staff | Preventive / each payment | R2, R3, R9 |
| C2 | New beneficiaries and changes to beneficiary bank details are verified by an independent call-back to a number on file before first use; the verification is recorded against the beneficiary record | Preventive / each new or changed beneficiary | R1 |
| C3 | Out-of-pattern instructions (new beneficiary, first payment to a country, amount above the customer’s or cost centre’s history, urgency, changed remittance details) are flagged by rule and held for verification with the originator through a known channel | Preventive / each flagged payment | R1, R5 |
| C4 | Every payment is screened against sanctions lists before release; alerts are dispositioned by a second person; screening lists are updated within the regulator’s expectation and the screening engine is tested with known hits | Preventive / each payment, continuous | R4 |
| C5 | Access to payment systems and channels uses multi-factor authentication and named credentials; privileged and administrator rights sit outside operations; user access is reviewed quarterly against HR and leavers are removed within one business day | Preventive-detective / continuous, quarterly | R2, R5 |
| C6 | Payment files from ERPs and other sources are transmitted through authenticated, integrity-checked channels (host-to-host with hashing or signing); no file is editable between generation and transmission; totals are confirmed against the source system | Preventive / each file | R7 |
| C7 | Per-transaction, daily and channel limits are configured to the delegation of authority; changes require approval outside operations and are logged and reviewed monthly | Preventive-detective / continuous, monthly | R9, R2 |
| C8 | Exception queues (repairs, rejects, returns, recalls, suspense) are worked to an SLA measured in hours; a recall procedure exists with the bank’s or the rail’s contact points and is exercised; suspense is aged and reported daily | Detective / continuous | R6 |
| C9 | Payment system activity is reconciled daily to the core ledger and to the bank or the rail’s settlement report by someone outside payment operations; differences are investigated the same day | Detective / daily | R8, R2 |
| C10 | A tested manual fallback exists for each rail, with the same dual control and verification requirements and a log of everything processed under it; fallback use is reported to management | Preventive / on invocation, tested annually | R10 |
Load the matrix into the RCM Workbench and rebuild it against the walkthrough with the RCM template guide. Most of these controls are configuration in a modern payment system, which is good news for testing (test of one per scenario plus change control) and bad news for the auditor who inspects the policy instead of the configuration.
The 14-test program
Sample sizes follow the standard conventions and go in the sampling memo; tests marked with a triangle are full-population analytics and run first. For automated controls, use the test-of-one method with the general IT controls confirmed.
- Dual-control configuration. Inspect the payment system’s role design and limits. Attributes: no role combines entry and release; release limits equal the delegation; second-releaser threshold configured; configuration changes require approval outside operations and are logged. Test of one per scenario, including an attempt to release one’s own entry.
- ▲ Self-approved and single-user payments. Full population of payments in the period where the entering and releasing user are the same, or where release was by a user outside the role design, or by a shared credential. Every hit is a control failure regardless of amount.
- Beneficiary verification. Population: new beneficiaries and changed bank details in the period. Sample 25 or all. Attributes: call-back to a number on file (not from the request), before first payment, recorded against the record, performed by someone other than the initiator.
- Out-of-pattern holds. Inspect the rule set and sample 25 held items. Attributes: rules cover new beneficiary, first country, amount outliers and urgency; held items verified with the originator through a known channel; releases from hold approved and documented; the rule set cannot be switched off by operations.
- Sanctions screening. Inspect list-update evidence and run a test-hit through the engine (with compliance’s agreement). Sample 25 alerts. Attributes: screened before release; alerts dispositioned by a second person with a rationale; no bulk closures; escalation to compliance for true matches.
- Access and credentials. Reconcile the payment-system user list to HR; inspect MFA enforcement and administrator assignments. Attributes: every user a current employee with a role matching their job; leavers removed within one business day; no shared credentials; administrators outside operations; quarterly review evidenced, following the user access review guide.
- File integrity. Trace five payment files from ERP generation to bank receipt. Attributes: file hash or signature verified; no editable stage on a shared drive; totals agreed to the source run; rejected files reported and re-sent under control.
- Limits and cut-offs. Inspect the limit configuration and the change log. Attributes: limits match the delegation; changes approved and reviewed monthly; after-cut-off processing follows a documented exception path with the same dual control.
- Exception queues and recalls. Inspect the queues at three dates and sample 25 exceptions. Attributes: worked within the SLA; suspense aged and reported; recall procedure documented with contacts; every recall in the year timed from detection to request (the number that decides whether the money came back).
- Fraud log and stopped attempts. Inspect the year’s fraud log. Attributes: every attempt logged with the control that stopped it; losses reported with root cause; the kill-chain request made within hours where a loss occurred; lessons fed back into the rule set in test 4.
- Daily reconciliation. Sample 20 business days. Attributes: payment system to ledger and to the rail’s settlement report reconciled the same day by someone outside operations; differences investigated; no aged unreconciled items written off without approval.
- Manual fallback. Inspect the fallback procedure and the last test or invocation. Attributes: dual control and verification preserved; log of items processed; reconciliation after restoration; test performed within the year with results acted on.
- Channel and customer-side controls (banks). For customer-initiated wires and online banking: agreements specify the security procedure; the procedure is enforced in the channel (dual approval, tokens, limits); customer education on business email compromise evidenced; call-back thresholds for customer wires applied and recorded.
- Reporting and governance. Inspect management reporting for the year. Attributes: volumes, exceptions, fraud attempts and losses, limit changes and access reviews reported to a committee that meets; findings from prior reviews closed; the payments risk assessment refreshed for the new rails (instant payments, ISO 20022) and the year’s attack patterns.
The analytics that find the exposure before the loss
| Analytic | Logic | What a hit means |
|---|---|---|
| Same-user entry and release | Entering user equals releasing user, or release by a user outside the release role, or within seconds of entry | Dual control defeated by role design, delegation or a shared login |
| First payment to a new beneficiary | Payments to beneficiaries created or changed within N days, joined to the verification record | The BEC window; a payment released before the call-back |
| Beneficiary change then payment | Bank-detail changes followed by a payment within 10 days, especially large or urgent ones | The classic redirection pattern; verify every one |
| Duplicate and near-duplicate payments | Same beneficiary, amount and date; same reference with different amounts; two releases of one file | Fat-finger releases; a file sent twice; the Revlon pattern in miniature |
| Limit hugging and splitting | Payments just under a release limit; several payments to one beneficiary in a day whose sum exceeds a limit | Structuring around the delegation |
| Off-hours and fallback activity | Releases outside operating hours, on weekends, or during fallback windows, by user | Unsupervised activity; fallback used more than reported |
| Recall timing | Time from detection to recall request for every recall in the year | Whether the kill chain has any chance; the number to report |
| Leaver activity | Any payment-system activity by a user after the HR termination date | Access not removed; an audit finding and possibly a fraud |
| Screening alert closure rates | Alerts closed per analyst per hour; closures with identical rationales | An analyst clearing the queue rather than reading it |
Worked example: Lakeshore Bancorp’s wire operations audit
Lakeshore Bancorp is the 9-billion-dollar regional bank used across this site’s banking examples, with a 22-person internal audit function. Its wire room sends about 118,000 outgoing wires a year, 19.4 billion dollars, from three sources: customer instructions taken at branches, business customers’ online banking with dual approval, and the bank’s own treasury and loan operations. The previous year-end’s SOX work, written up in the control deficiency evaluation guide, had found a significant deficiency in the wire platform’s user access review: 4.2 million dollars of wires had been entered and released by the same user under a supervisor role, and three terminated users had remained live for between 27 and 61 days. Management remediated the role design and the leaver process before year-end, and the audit committee asked for a full operational review of the wire room the following year, budgeted at 480 hours, to establish whether the rest of the process was any better than the part the SOX work had touched. The analytics ran on the full year’s payments before fieldwork, and the walkthrough spent two mornings in the wire room and one in a branch.
| Test | Population and sample | What it found | Where it went |
|---|---|---|---|
| 1. Dual-control configuration | Role design; limits; test of one per scenario | Entry and release separated for all production roles after the remediation; a contingency “wire supervisor” role retained entry-and-release rights up to 250,000 dollars for outages, assigned to two people, used once in the year. | Finding, High (with test 6) |
| 2. Self-approved payments | Full year, 118,000 wires | 61 same-user wires before the remediation date, 4.2 million dollars as reported; none after; the single contingency use was dual-approved on paper. | Confirmed remediation; retained in the report as context |
| 3. Beneficiary verification | Customer wires above 25,000 dollars initiated at branches: 60 sampled | 21 of 60 had no recorded call-back to a number on file; branches had called the number written on the wire request form. Online-banking wires were verified in-channel. | Finding, High |
| 4. Out-of-pattern holds | Rule set; 25 held items | Rules covered new beneficiary, first country and amount outliers; 14 releases from hold in the sample were made by the wire supervisor with no verification note. | Finding, Medium |
| 5. Sanctions screening | List updates; test hit; 25 alerts | Lists updated within a day; test hit caught; 340 alerts closed by one analyst in one afternoon with an identical rationale, all false positives on review, none documented individually. | Finding, Medium |
| 6. Access and credentials | User list vs HR; MFA; administrators | Leaver removal within one day after remediation; quarterly review evidenced; two branches operated a shared “branch wire” credential used by four tellers each. | Finding, High (with test 1) |
| 7. File integrity | Five files from treasury and loan operations | Host-to-host with hashing; totals agreed; no editable stage. | No finding |
| 8. Limits and cut-offs | Configuration; change log | Branch wire limits raised 31 times in the year with branch-manager approval only; the policy requires operations-risk approval. | Finding, Medium |
| 9. Exceptions and recalls | Queues at three dates; 25 exceptions; all 38 recalls | Median time from detection to recall request 31 hours; nine recalls took more than three days; suspense held 86,000 dollars older than 60 days. | Finding, Medium |
| 10. Fraud log | The year’s log | 14 customer-side business email compromise attempts stopped, 2.3 million dollars; two losses totalling 148,000 dollars, one recovered in part (61,000 dollars) through a kill-chain request made within eight hours; the other requested after four days and lost. | Evidence for the recall finding |
| 11. Daily reconciliation | 20 business days | Performed daily to the ledger and Fedwire settlement, by a wire-room team member rather than someone outside operations; differences cleared same day. | Finding, Medium |
| 12. Manual fallback | Procedure; last test | Tested annually; the manual wire form had a single signature line; the test log showed dual control preserved in practice. | Finding, Low |
| 13. Channel and customer-side controls | Agreements; channel configuration; waivers | Business online banking enforced dual approval by default; 210 of 1,900 business customers had opted out to single approval; written waivers acknowledging the security procedure were on file for 136 of them. | Finding, Medium (loss allocation exposure under UCC 4A) |
| 14. Reporting and governance | Committee packs for the year | Volumes, fraud attempts and access reviews reported quarterly; no risk assessment yet for the bank’s new instant-payment send capability. | Finding, Low |
The report carried nine findings, two High, five Medium and two Low, and an overall rating of Needs Improvement, which management accepted without argument because the recall finding had a number attached to it that nobody could dispute: one customer’s 87,000-dollar loss had been recoverable for about a day, and the request went out on day four. The branch call-back finding was the one that changed behaviour: the wire request form was redesigned so that the verification number comes from the customer record, printed by the system, and the branch signs that it called that number. The shared branch credentials were replaced with named logins in three weeks. The waiver gap became a project with the legal department, because 74 business customers were operating single-approval wires with no written acknowledgement of the procedure they had declined, and under Article 4A that is the bank’s exposure, not theirs. Three things generalise. Test the remediation of a known deficiency as a population, not as a sample, because the value of test 2 was the zero after the remediation date. Time every recall in the year, because the recall clock is the most persuasive number a payments audit produces. And read the customer agreements against the channel configuration, because the legal frame allocates the loss on the basis of what the bank offered and the customer accepted, not on what either believed.
The findings that recur, and wording that lands
Five findings account for most payments reports, and each lands in five-Cs form with the number that makes it undeniable. Dual control (“a contingency role permits entry and release of wires up to 250,000 dollars; 61 wires totalling 4.2 million dollars were released under it before remediation”). Beneficiary verification (“21 of 60 branch-initiated wires above 25,000 dollars were verified by calling the number on the request form rather than a number on file; the procedure requires an independent number, and this is the pattern in every business email compromise loss the bank recorded this year”). Recall timing (“the median time from detection to recall request was 31 hours and nine of 38 recalls took more than three days; the one loss recovered this year was requested within eight hours, the one not recovered after four days”). Access (“two branches operate a shared wire credential used by four tellers each, which defeats the audit trail and the dual-control design”). Limit governance (“branch wire limits were raised 31 times in the year on branch-manager approval; policy requires operational-risk approval”). Write the cause as a design decision (a role kept for outages; a form that invites the wrong number; a recall procedure that starts with a meeting) and follow the root cause guide for the step between.
Scoping variants: payment factory, small company, instant payments
Corporate payment factory or treasury desk: the same program applies with the bank’s controls now on the other side of the interface; the tests that matter most are beneficiary verification in the vendor master (which lives in the vendor master audit and the accounts payable guide), file integrity from the ERP to the bank, dual release in the treasury system, and the agreement with each bank, read against what the company actually operates; add the SWIFT attestation if the company is a member. Small company on an online banking portal: the audit is the portal’s configuration (dual approval on, limits set, tokens named, administrator not the bookkeeper), the beneficiary call-back done by someone other than the person who received the request, and the bank reconciliation performed by someone else; the AFP survey’s finding that cheques remain the most targeted instrument means positive pay, or the decision not to buy it, belongs in the report. Instant payments (RTP and FedNow): irrevocable, settled in seconds, available at any hour; the controls that matter are limits set low and raised deliberately, holds on first payments to new beneficiaries that do not rely on a human being awake, and a fraud-monitoring capability that works at night; the payments risk assessment must be refreshed before the send capability is switched on, not after. Banks: add the regulatory layer (sanctions program expectations, the FFIEC’s authentication guidance, ISO 20022 data quality) and the customer-agreement layer above; the deficiency-evaluation logic for SOX in the control deficiency guide applies to whatever the operational review finds.
Where to go next
Audit payments in the order the loss happens: initiation and verification first, because that is where business email compromise wins; dual control and access second, because that is where insiders win; exceptions and recalls third, because that is where a recoverable fraud becomes a loss; and reconciliation and governance last. Test configuration rather than policy, time every recall, and read the agreements. The program above is a complete starting position; size it with the sampling grid, build the file like the model workpaper, and report it with the report template. The function that owns the accounts is covered in how to audit treasury; the accounting for what leaves and arrives in how to audit cash management and bank reconciliations; and the decision about what to pay in how to audit accounts payable.
Related guides
- How to audit treasury — the function that owns the accounts and mandates
- How to audit cash management and bank reconciliations — the accounting side of the same flow
- How to audit accounts payable — the process that decides what gets paid
- How to audit the vendor master — beneficiary integrity at source
- Control deficiency evaluation — Lakeshore’s wire-platform deficiency and how it was rated
- User access reviews — the payment-system access test in depth
- Testing automated controls — test of one for configured controls
- Segregation of duties — entry, release, reconcile
- Incident response audit — the kill-chain request as an incident procedure
- Fraud red flags — business email compromise patterns
- Risk and control matrix template — turning the starter matrix into yours
- Audit sample sizes: 25, 40, 60 — the sampling conventions
- The five Cs of audit findings — the structure the findings above follow
- Audit issue log template — where the actions go
- All fieldwork and testing guides and all operational risk guides
Leave a Reply