Section 75 is a UK consumer protection provision that can make credit providers jointly liable for certain disputes linked to purchases. In BNPL programmes, it matters because it increases the importance of accurate records, clear disclosures, and a defensible approval path.
Expanded Definition
consumer Credit Act Section 75 is a statutory consumer remedy, not a payment technology, and in practice it shifts part of the dispute burden onto the credit provider when qualifying purchases go wrong. In BNPL and other credit-backed checkout flows, that means transaction records, merchant identity, product scope, and consumer disclosures must be precise enough to reconstruct what was approved and on what basis. The provision is often discussed alongside consumer protection law and card scheme chargeback processes, but it is distinct because it concerns legal liability rather than only payment reversal mechanics. For NHI-managed commerce systems, the relevance is operational: service accounts, API keys, and automated approval workflows must preserve traceability so that a dispute can be answered with evidence rather than inference. Guidance across vendors varies on how much logging is sufficient, but no single standard governs this yet. The most common misapplication is treating Section 75 as a general refund rule, which occurs when organisations assume it applies to every payment method or fail to check whether the purchase and credit arrangement actually qualify.
For control expectations around traceability and retention, organisations often map this kind of workflow evidence to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where auditability and accountability are required.
Examples and Use Cases
Implementing Section 75 rigorously often introduces documentation overhead, requiring organisations to weigh faster checkout experiences against stronger dispute defensibility.
- A BNPL provider stores the merchant-of-record, invoice, and consumer consent trail so a disputed item can be tied back to the original approval path.
- An e-commerce platform uses an AI agent to flag orders that may fall within Section 75 thresholds, then requires human review before credit is extended.
- A payment operations team preserves request and response logs from service accounts so refund, cancellation, and liability decisions can be audited later.
- A compliance group aligns its evidence model with Ultimate Guide to NHIs to reduce the chance that automated workflows lose the context needed for consumer disputes.
- A merchant integrates policy checks with NIST SP 800-53 Rev 5 Security and Privacy Controls to keep approvals, changes, and notifications reviewable.
In practice, the term also matters where automated checkout, delegated approvals, or third-party processors obscure who authorised the credit and what exactly was sold.
Why It Matters in NHI Security
Section 75 becomes an NHI security issue when automated commerce depends on service accounts, API keys, or AI agents to approve, price, route, or document transactions. If those identities are overprivileged, poorly logged, or shared across systems, the organisation may be unable to prove what happened when a dispute arrives. That problem is not abstract: NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, as documented in the Ultimate Guide to NHIs. In a consumer-credit context, weak identity hygiene can undermine the evidentiary trail that Section 75 depends on. This is why records retention, least privilege, and immutable audit logs are not just security controls but dispute controls. Organisations typically encounter the cost of poor traceability only after a chargeback, complaint, or legal claim, at which point Section 75 becomes operationally unavoidable to address.
That governance pressure also aligns with broader control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, where accountability and evidence preservation are core requirements.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Section 75 depends on clear access accountability and least privilege in automated credit flows. |
| NIST SP 800-63 | Identity assurance principles help validate who or what authorized a consumer credit workflow. | |
| NIST Zero Trust (SP 800-207) | Zero Trust reinforces continuous verification for service identities handling consumer credit data. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Improper secret handling can weaken the audit trail behind credit approvals and disputes. |
| NIST AI RMF | AI risk practices apply when agents influence credit approvals or dispute records. |
Use strong identity proofing and authentication for systems that create or approve credit decisions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
