Who is accountable when onboarding fraud rises in a BNPL programme?

Accountability usually sits with the lender or merchant operating the onboarding journey, because they own the customer experience, the control design, and the fraud outcomes. Partner programs can improve execution, but they do not remove responsibility for verifying identity, protecting consent, and setting the right onboarding thresholds for risk.

Why This Matters for Security Teams

When onboarding fraud rises in a BNPL programme, the accountability question is usually less about who triggered the fraud and more about who designed the onboarding control environment. The lender or merchant operating the journey owns the thresholds, the consent flow, the identity checks, and the exception handling. That makes this a governance issue as much as a fraud issue, especially where partner-led acquisition, embedded finance, or outsourced verification can obscure decision ownership.

Security and risk teams should treat rising fraud as a signal that the onboarding model is misaligned with the product’s risk appetite. Fraud often concentrates where identity proofing is weak, device signals are over-trusted, or manual review is too slow to stop synthetic or mule-led applications. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for mapping control ownership to access, authentication, and monitoring expectations, while FATF Recommendations and KYC guidance help frame identity and transaction risk in regulated finance contexts. In practice, many teams only discover that ownership is unclear after fraud losses have already been booked and partner contracts are already under strain.

How It Works in Practice

Accountability should be assigned to the entity that can change the control design, not the entity that merely supplies a channel or verification service. In BNPL onboarding, that usually means the programme owner must define the acceptance policy, the identity evidence required, the step-up checks for risky cohorts, and the review path for exceptions. Partners can execute parts of the journey, but they do not remove the need for a clear control owner.

A practical operating model usually includes:

• Named control ownership for each onboarding step, including identity proofing, consent capture, and fraud review.
• Risk-tiered onboarding thresholds that change by product, geography, device confidence, and applicant behaviour.
• Escalation rules for synthetic identity indicators, rapid repeat applications, and suspicious referral patterns.
• Independent monitoring of partner performance, including false accept rates and fraud loss attribution.
• Documented decision logs so the business can prove why an application was accepted, declined, or queued for review.

NHIMG’s research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges, which is a useful reminder that fraud control failures often hide in access and integration design, not just customer-facing screens. The same operational discipline applies in onboarding chains that use automated checks, orchestration APIs, and external decision services. For baseline governance expectations, the Ultimate Guide to NHIs is a strong starting point.

These controls tend to break down when the BNPL programme is distributed across multiple brands, processors, and verification vendors because no single party owns the full fraud outcome.

Common Variations and Edge Cases

Tighter onboarding controls often increase abandonment, manual review cost, and partner friction, so organisations have to balance fraud reduction against customer conversion and regulatory timing. That tradeoff becomes more acute in BNPL because the highest-risk applicants are often the ones most sensitive to extra friction.

There is no universal standard for exactly how much fraud loss should sit with the lender versus the merchant in every partnership structure. Best practice is evolving, but the accountability principle is consistent: the party that sets the risk policy and controls the customer decision flow is responsible for the outcome. In white-label or embedded BNPL models, that can still be the lender even when the merchant owns the storefront experience.

Edge cases often arise when:

• Verification is outsourced, but decline logic remains opaque to the programme owner.
• Merchant acquisition teams optimise for conversion while risk teams measure only portfolio loss.
• Legitimate high-friction cohorts, such as thin-file customers, are underserved by rigid rules.
• Fraud is split across chargeback, first-party abuse, and identity theft, making attribution noisy.

For policy and control mapping, current guidance suggests aligning onboarding decisions to documented identity risk criteria and retaining clear evidence of who approved each exception. The NIST SP 800-53 Rev 5 Security and Privacy Controls and the FATF Recommendations — AML and KYC Framework both reinforce that ownership, monitoring, and evidence matter as much as the detection tooling itself.

Related resources from NHI Mgmt Group

• Who is accountable when a password programme leaves users exposed to phishing and weak credential reuse?
• Where does cross-environment agent discovery fit in an IAM programme?
• Who is accountable when deepfake fraud bypasses customer onboarding controls?
• Who is accountable when synthetic identity fraud inflates onboarding growth?