Both, but the identity control is the one that usually fails first. Settlement systems are only as safe as the identities allowed to quote, approve, execute, and reconcile. The practical test is whether every machine, operator, and partner has a scoped role with auditable authority, not standing access.
Why settlement infrastructure belongs in identity governance
Settlement infrastructure is not just a transaction rail, because the actors that can quote, approve, execute, and reconcile transactions are part of the control surface. If those authorities are not tightly scoped, the system can look operationally sound while still being exposed to excessive privilege, shared access, and weak accountability. That is why identity has to be treated as the first-class control.
The payments lens still matters, but mainly as a downstream control layer. Payments controls focus on integrity, sequencing, reconciliation, fraud prevention, and record accuracy; identity controls determine who is allowed to initiate those actions in the first place. In practice, the stronger the settlement privilege model, the less the business depends on informal trust in operators or partner systems.
Teams often miss that settlement failures are frequently permission failures. A role that is too broad, a partner connection that is not constrained, or a reconciliation function that can also execute changes turns an ordinary control gap into a high-impact access problem. For that reason, settlement infrastructure should be mapped to the identity plane as well as the payment flow.
When teams build the control model around machine, operator, and partner authorities, they can distinguish between payment integrity controls and the identities that may exercise them. That is where Identity Security Programme Guide becomes useful, because settlement governance depends on ownership, role definition, and operating model clarity before it depends on transaction rules.
What usually fails first in settlement environments
The first breakage is usually not a missing payment rule, it is an identity that can do too much. Shared operator accounts, long-lived service credentials, and partner access that is broader than the business process all create conditions where a legitimate path can be abused without triggering obvious payment anomalies. That is especially dangerous in environments where approvals and execution are close together.
Another common failure mode is environment and function collapse. If the same identity can test, approve, reconcile, and sometimes remediate, the organisation loses the separation that makes settlement controls auditable. The operational effect is subtle: the process still runs, but the evidence no longer proves who did what, when, and under which authority.
Visibility is also a failure point. If teams cannot inventory the machine and human identities touching settlement workflows, they cannot reliably attest to least privilege or recertify access. The most useful question is not whether the payment system is “secure”, but whether every actor has a scoped, reviewable role with a defensible business purpose.
That is the logic behind Top 10 NHI Issues: visibility gaps, excess privilege, and unmanaged credentials are control failures that become operationally visible only after they have already weakened the settlement path.
How to test the control boundary in practice
The practical test is simple: if you remove the identity layer, does the settlement control still tell you who is authorised to do what? If the answer is no, then the real control is identity governance, not the payment workflow itself. This matters because payment controls can validate events, but identity controls determine whether the event should have been possible at all.
For practitioners, the best boundary test is to map each settlement action to a named role, approval path, and evidence trail. Quote, approve, execute, and reconcile should not collapse into the same authority unless the use case is truly low risk and explicitly accepted. Where automation is used, the automation identity needs the same scrutiny as a human operator.
Partner access deserves the same treatment as internal access. A third party that can submit, amend, or confirm settlement instructions is not just an integration dependency, it is an identity with delegated authority. That is why Identity Convergence Guide is relevant here, because converged control over workforce, privileged, partner, and machine identities is what makes the boundary intelligible.
For teams building a more formal control model, Identity Security Posture Management (ISPM) Guide helps frame the checks that matter most: standing access, stale entitlements, dormant credentials, and role drift across the settlement path.
Risk and Threat Considerations
Settlement environments are attractive because a single overprivileged identity can influence money movement, reconciliation, and downstream reporting. The risk is not only fraudulent transfer, but also quiet manipulation of records, approvals, or exception handling that makes the compromise harder to spot.
Failure mechanism: Excessive privilege, shared credentials, or weak partner delegation lets an attacker or insider use a legitimate path to quote, approve, execute, or reconcile without clear separation of duties.
Impact: The organisation can lose transaction integrity, auditability, and containment at the same time, which turns a local access issue into a business-critical settlement event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Settlement actors often include service and machine identities. |
| AC-6 — Least Privilege | The question centers on scoped authority for quote, approve, execute, and reconcile actions. | |
| AU-2 — Event Logging | Auditable authority is essential when settlement actions must be attributable. | |
| Recommendation — Authenticate non-human settlement actors with service-specific controls. Restrict settlement roles to the minimum authority each function needs. Log settlement approvals and executions with attributable identity context. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Settlement authority must be governed as a controlled access model. |
| A.8.5 — Secure authentication | Settlement systems depend on strong authentication for operators and services. | |
| Recommendation — Define and enforce settlement access rules by role and need. Use strong authentication for every settlement-facing identity. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Machine and service identities in settlement can become overpowered. |
| NHI-07 — Long-Lived Secrets | Settlement access often relies on credentials that should not persist indefinitely. | |
| NHI-01 — Improper Offboarding | Settlement partners and operators must lose access when they leave or change role. | |
| Recommendation — Audit settlement machine identities for unnecessary privileges. Replace long-lived settlement secrets with shorter-lived credentials. Revoke settlement access promptly when roles or vendors change. | ||
Practitioner Guidance
What to prioritise: Start with the identities that can move value or change transaction state, not with the broader payment application stack. If a machine or operator can influence settlement without a tightly scoped role, that is the first control to fix.
What to verify: Confirm that every settlement-related identity has a named owner, a minimal role, an auditable approval path, and a revocation process. If access cannot be recertified on demand, the control is not mature enough for settlement-critical use.
Decision rule: If the control is meant to prevent unauthorised settlement activity, treat it as an identity control first and a payments control second. Use payment controls to validate outcomes, but use identity controls to constrain who can create those outcomes.
Practitioner takeaway: The safest settlement model is the one where payment logic can detect problems, but identity governance prevents most of them from being possible in the first place.
Related resources from NHI Mgmt Group
- When should security teams treat identity as infrastructure?
- What do identity teams get wrong when they treat infrastructure ownership as control?
- What do security teams get wrong when they treat privileged account management as one control instead of separate account, user, and identity problems?
- How should security teams limit control over Active Directory so attackers cannot use identity infrastructure to move across the environment?