Join our Newsletter — 33% off our NHI Course

How should finance and identity teams share accountability for payment fraud?

Finance teams should own payment rules, approval logic, and exception handling, while identity and access teams help ensure those rules are tied to verified people, vendors, and roles. The key is a shared operating model where vendor changes, approver access, and transaction monitoring are correlated. Without that split ownership, fraud gaps fall between teams.

How finance and identity teams share accountability without blurring ownership

Payment fraud sits at the intersection of business process and access control, so the accountability model has to reflect both. Finance owns the payment policy, approver rules, vendor master decisions, and exception handling. Identity teams own the assurance around who can approve, change, or initiate those actions, and whether access is still legitimate when roles or vendors change.

A workable split is to make finance accountable for the transaction logic and identity accountable for the access paths that can activate or bypass it. That means both teams need a shared view of approver status, vendor master changes, step-up checks, and monitoring signals, because fraud usually succeeds when one team assumes the other is watching the same control.

This is also where ownership needs to be explicit for false positives and exception flow. Finance can decide which patterns should block, queue, or require secondary review, while identity teams make sure the people who can override those decisions are tightly governed, recertified, and auditable. If the exception process is left informal, fraud can hide inside routine business discretion.

Where the control boundary should sit in practice

The cleanest boundary is to separate business authorisation from identity authorisation. Finance should define who is allowed to request payment, approve it, modify bank details, or override thresholds. Identity and access teams should enforce whether those roles are real, current, and limited to the right people or service accounts. That split avoids the common mistake of treating “approved by the business” as a substitute for valid access.

The boundary also needs to cover vendor changes, because vendor bank account updates and approver changes are often the highest-risk points in the payment flow. Finance should own the business validation of those changes, while identity teams ensure the individuals making them have the right role, are not stale accounts, and are subject to the right recertification. If those checks are separated, the control breaks.

For teams that need a broader model of identity governance, the NHI Lifecycle Management Guide is useful because it frames provisioning, visibility, and offboarding as a single control loop. The same lifecycle logic applies when payment access is tied to approver roles, finance systems, or delegated administrative functions.

The identity side also benefits from a clear inventory of who can touch payment workflows, not just who “should” be involved. NHIMG’s Identity Security Programme Guide helps map that operating model across ownership, governance, and accountability so the finance process and access model do not drift apart.

Fraud signals that should be correlated across both teams

Payment fraud rarely presents as a single bad event. It usually shows up as a chain: a vendor change, a new approver path, a rushed exception, or a payment sent through an unusual route. Finance teams often see the business anomaly first, while identity teams see the access anomaly first. The value comes from correlating both.

That correlation should include approver access changes, unusual approvals, bank-detail edits, dormant account reactivation, and cases where the same person can both request and approve. It should also include cases where a trusted business process is used with unusual timing or urgency, because fraud often exploits the assumption that a normal workflow is automatically safe.

When the question is how to make that correlation operational, the most useful internal reference is Top 10 NHI Issues, especially the themes around ownership, excessive access, and lifecycle gaps. Even when the payment workflow is human-led, the same failure pattern appears whenever access, ownership, and monitoring are split across teams.

The best external analogue is the payment-fraud playbook in regulated environments, where controls are designed to prevent a single compromised path from authorising movement of funds. The practical lesson is that transaction monitoring only works when it sees both the business event and the identity event, not one or the other in isolation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 AC-6 — Least Privilege Payment approval and override access should be limited to the minimum needed.
IA-5 — Authenticator Management Approver and privileged access depends on controlled credentials and lifecycle.
AU-6 — Audit Record Review, Analysis, and Reporting Fraud detection depends on correlating approval, vendor-change, and access logs.
Recommendation — Restrict payment and vendor-change privileges to the smallest viable role set. Rotate and revoke credentials used for payment approvals and exceptions. Review payment, vendor, and identity logs together to spot abuse paths.
NIST CSF 2.0 PR.AA-05 — Identity Management, Authentication, and Access Control Payment workflows need role-bound access tied to verified users and changes.
DE.CM-01 — Continuous Monitoring Shared monitoring is needed to detect anomalous payment and access events.
Recommendation — Tie payment authority to verified identity and enforce role-based access checks. Monitor payment and identity events continuously for abnormal changes and approvals.
ISO/IEC 27001:2022 A.5.15 — Access control Separating approval authority from access authority is an access-control issue.
A.5.16 — Identity management Approver and vendor-change accountability depends on trustworthy identity records.
Recommendation — Define and enforce who may request, approve, and override payment actions. Maintain accurate identity records for all payment approvers and change actors.
CIS Controls v8 CIS-5 — Account Management Payment fraud often exploits stale or excessive accounts and approvals.
CIS-8 — Audit Log Management Correlating vendor, approval, and access activity requires usable logs.
Recommendation — Remove stale access and review accounts that can alter payment flows. Keep logs that let finance and identity teams trace payment-related changes.

Practitioner Guidance

What to prioritise: Define one joined control map for payment change, approval, and exception handling. If a control can move money or approve a change, name both the business owner and the identity owner explicitly.

What to verify: Confirm that vendor edits, approver changes, and override rights all produce reviewable evidence. The important test is whether an auditor or investigator can reconstruct who changed what, who approved it, and under which access path.

Decision rule: If a user can both alter a payee record and approve the resulting payment, treat that as a segregation-of-duties failure until proven otherwise. If the workflow depends on “trusted people” rather than bounded access, the control is too weak.

Common mistake: Teams often separate fraud monitoring from access governance and assume alerts will compensate for weak role design. In practice, that pushes detection downstream and increases the chance that the first signal is a loss, not a block.

Practitioner takeaway: Payment fraud accountability works when finance owns the business decision and identity owns the authority to execute it, with shared monitoring at the handoff points where those two worlds meet.