Accountability does not stop at the merchant. Visa’s model pushes pressure up to the acquirer, which means portfolio management, merchant thresholds, and remediation oversight become shared responsibilities. Fraud operations, IAM, and payments governance need common reporting so one merchant’s behaviour does not damage the wider book.
Why This Matters for Security Teams
When merchant disputes push an acquirer into an excessive band, the operational issue is not just bad merchant behavior. The real risk is concentration: one merchant can create chargeback, fraud, and remediation pressure that affects portfolio standing, scheme monitoring, and downstream controls. That makes accountability a governance problem as much as a payments problem. NHI Mgmt Group’s Ultimate Guide to NHIs shows how weak visibility and excessive privilege turn isolated issues into enterprise-wide exposure, and the same pattern appears in payments oversight. Security teams also benefit from control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where monitoring, accountability, and corrective action must be assigned clearly. In practice, many acquirers only discover how fragile ownership is after portfolio remediation has already become urgent, rather than through proactive merchant governance.
How It Works in Practice
Accountability usually sits with the acquirer, but it is distributed across several functions. Merchant relationship teams own onboarding and commercial terms, fraud operations monitor dispute patterns, compliance tracks scheme thresholds, and risk management decides when to intervene. If the acquirer uses payment processors, aggregators, or program managers, those third parties may influence visibility, but they do not remove the acquirer’s responsibility to manage the book. That is why evidence, thresholds, and escalation paths need to be explicit, not implied.
A workable control model usually includes:
- Merchant-level dispute dashboards with banding, trend, and root-cause analysis.
- Escalation rules that trigger when a merchant approaches a threshold, not after it is breached.
- Documented remediation plans that assign owners, timelines, and review checkpoints.
- Shared reporting between fraud, compliance, operations, and IAM so account access, merchant permissions, and exception handling are visible together.
- Revocation or restriction steps for merchants that ignore repeated corrective actions.
This is where NHI governance offers a useful parallel. Visibility failures are rarely isolated, and NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. The same lack of visibility in payments makes it hard to tell whether a dispute spike is a one-off event, a process failure, or a pattern that requires account-level action. The practical answer is to make responsibility measurable through reporting and escalation, then tie it to documented oversight. These controls tend to break down when portfolio data is fragmented across processors and internal teams because no single function can see the merchant’s full dispute trajectory.
Common Variations and Edge Cases
Tighter merchant monitoring often increases operational overhead, requiring organisations to balance faster intervention against commercial friction and manual review load. Current guidance suggests that the right ownership model depends on the merchant type and acquiring structure, but there is no universal standard for this yet.
Edge cases matter. In sponsored or facilitated models, the acquirer may carry the formal accountability even when another party manages onboarding or servicing. In high-volume verticals, a single merchant can move quickly from acceptable to excessive, so static monthly reviews are usually too slow. In these cases, near-real-time exception reporting is more effective than end-of-cycle review. Similarly, if disputes are driven by product design or unclear descriptor practices, fraud alone cannot fix the issue. Compliance, merchant success, and technical teams need to participate in remediation.
This is also where hard control language helps. The current best practice is to treat excessive-band exposure like a governed exception, not an informal warning. That means assigning a single accountable owner, setting a decision deadline, and documenting whether the merchant is being remediated, limited, or exited. For teams building broader control maturity, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference for accountable monitoring and corrective action, while the Ultimate Guide to NHIs reinforces why shared visibility is essential when multiple systems and owners influence the outcome.
