How should security teams handle customer identification and due diligence for non-face-to-face business relationships in Kenya?

Why This Matters for Security Teams

Non-face-to-face onboarding creates a higher risk of impersonation, document fraud, and synthetic identities because the organisation cannot rely on in-person checks or informal corroboration. For Kenyan business relationships, the practical issue is not just collecting identity data, but proving that the customer was identified before activation and that due diligence matched the stated risk. That makes identity assurance, auditability, and escalation rules central to the control design, not optional extras.

Security teams often underestimate how quickly weak onboarding becomes a downstream fraud, AML, or account takeover problem. A process that is acceptable for low-risk digital access may still fail regulatory expectations if it cannot show who was verified, what evidence was checked, and why the customer was approved, rejected, or placed under enhanced monitoring. Current guidance suggests aligning verification strength to risk, then retaining evidence that the workflow was consistently applied. For baseline control design, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for structuring identity, audit, and access governance. In practice, many security teams discover the weakness only after suspicious activity, disputed onboarding, or a regulator asks for the full decision trail.

How It Works in Practice

A sound non-face-to-face process starts with customer identification before service activation, then layers checks based on the customer type, product sensitivity, delivery channel, and geographic risk. The goal is not simply to collect a scan of an ID document. It is to establish a defensible identity record that supports ongoing due diligence, periodic refresh, and trigger-based review when risk changes.

For Kenyan operations, the operational pattern usually includes document collection, validation of identity attributes, screening against internal and external risk signals, and escalation where the evidence is incomplete or inconsistent. Where the organisation uses remote onboarding technology, best practice is evolving, and there is no universal standard for this yet, but the process should still preserve integrity of evidence and an auditable chain of decision-making.

• Verify identity before activation, not after first use.
• Set risk tiers for individuals, entities, products, and channels.
• Apply enhanced due diligence when beneficial ownership, source of funds, geography, or transaction pattern raises concern.
• Record the data sources, reviewer decisions, and timestamps used in the onboarding decision.
• Trigger refresh reviews when customer behaviour, sanctions exposure, or account structure changes.

Where digital identity proofing is involved, NIST SP 800-63 Digital Identity Guidelines provides a useful model for assurance levels, evidence collection, and verifier confidence. Teams should also map the workflow to anti-money-laundering obligations, because identification quality and due diligence depth are inseparable from suspicious activity monitoring. These controls tend to break down when onboarding is outsourced across multiple vendors because no single party retains full visibility into evidence quality, reviewer judgment, and exception handling.

Common Variations and Edge Cases

Tighter customer verification often increases onboarding friction, manual review volume, and abandonment risk, requiring organisations to balance fraud prevention against customer experience and operational throughput. That tradeoff is especially visible in low-value digital products, diaspora onboarding, and agent-assisted sign-up flows, where rigid rules can block legitimate customers while loose rules create weak identity assurance.

The main edge cases are customers with limited documentary evidence, politically exposed persons, complex ownership structures, and relationships opened through intermediaries or third parties. In those scenarios, the control question becomes whether the organisation can still demonstrate reliable identification and proportionate due diligence, not whether every case was handled identically. NIST guidance on zero trust and identity assurance can help here, but it should be adapted to the business and legal context rather than copied mechanically. For broader control mapping, CISA Zero Trust Maturity Model is useful for understanding how identity confidence, segmentation, and monitoring reinforce one another, while FATF Recommendations remain important for risk-based customer due diligence expectations. The guidance breaks down in highly delegated agent networks, where frontline intermediaries collect evidence but the central compliance function cannot reliably reconstruct how each decision was made.

Related resources from NHI Mgmt Group

• How should security teams handle exposed credentials during M&A due diligence?
• How should security teams implement customer due diligence without creating too much onboarding friction?
• How should security teams handle SaaS offboarding when non-human identities are involved?
• How should security teams handle identity decisions when business context changes quickly?