How should security teams structure customer due diligence for non-face-to-face onboarding in Mexico?

Why This Matters for Security Teams

Non-face-to-face onboarding increases the gap between asserted identity and actual control over the account, which is why due diligence has to be designed as a risk decision rather than a box-ticking exercise. In Mexico, that means linking customer identification, source-of-funds expectations, sanctions and watchlist screening, and evidence retention into one auditable process. The practical question is not whether checks exist, but whether they can withstand challenge under local AML expectations and internal governance. The FATF Recommendations — AML and KYC Framework provide the baseline logic for risk-based customer due diligence, but implementation still has to fit the channel, product, and fraud profile.

Security teams often misread non-face-to-face onboarding as a pure compliance workflow, when it is also an identity assurance problem. If the verification path is weak, downstream access, transaction monitoring, and fraud controls inherit that weakness. Identity proofing, document validation, liveness or biometric checks where permitted, and sanctions screening need to be coordinated, not treated as separate approvals. Good programmes also define when enhanced due diligence is mandatory, so that higher-risk customers do not pass through the same automated path as low-risk ones. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it translates governance into concrete control expectations for identification, auditing, and monitoring. In practice, many security teams discover onboarding weaknesses only after account abuse or suspicious transaction patterns have already been observed, rather than through intentional control testing.

How It Works in Practice

A practical due diligence model starts by segmenting onboarding flows. Low-risk retail customers may be handled with streamlined checks, while higher-risk customers, politically exposed persons, cross-border relationships, or unusual product usage should trigger enhanced due diligence and manual review. The control set should be mapped to the relationship risk, not just the application channel. That is especially important where digital onboarding is used to open accounts remotely, because the verification burden shifts from in-person review to evidence quality, detection logic, and exception handling.

At a minimum, teams should connect the following steps into one recorded workflow:

• Identity verification using reliable documentary and, where appropriate, non-documentary evidence.
• Document authenticity checks and fraud screening for altered or synthetic identities.
• Sanctions, adverse media, and watchlist screening before account activation.
• Risk scoring based on product, geography, customer type, and expected activity.
• Ongoing monitoring for profile drift, unusual payments, or inconsistent behaviour.
• Retention of evidence that shows why the customer was approved, rejected, or escalated.

For governance, the strongest programmes separate policy approval from operational execution. Compliance should define the risk criteria, while operations and security implement the control path, logging, and exception approvals. Where biometrics or face match are used, the process should include quality checks, fallback paths for failed capture, and documented handling for false rejects. That matters because remote onboarding is only as strong as the evidence chain supporting it. If the institution cannot demonstrate that each check was applied consistently, it may have compliance exposure even when the customer was eventually verified. Current guidance suggests aligning customer due diligence with broader control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for audit logging, access control, and reviewability. These controls tend to break down when onboarding is distributed across multiple systems because evidence gets fragmented across identity vendors, CRM tools, and core banking platforms.

Common Variations and Edge Cases

Tighter due diligence often increases friction and onboarding abandonment, requiring organisations to balance fraud resistance against conversion and customer experience. That tradeoff becomes more visible in remote channels, where users may lack stable identity documents, use shared devices, or experience poor capture quality. There is no universal standard for this yet on every edge case, so current guidance suggests defining exception handling upfront instead of improvising approvals after the fact.

Special cases often include minors, foreign nationals, thin-file customers, expatriates, and customers who cannot complete facial verification due to accessibility or technical limitations. In those situations, a compliant programme should offer alternative evidence paths, more manual review, or controlled escalation rather than forcing a single digital method. Teams should also be careful not to equate stronger automation with stronger assurance. Automated document checks and biometric tools can improve consistency, but they do not replace judgment where the customer profile or transaction purpose is unusual.

Another common edge case is cross-functional ownership. Fraud teams may own detection, compliance may own policy, and security may own platform controls, but non-face-to-face onboarding fails when those groups do not share a common evidence standard. The best practice is evolving toward a single risk record per customer, with clear traceability from identity proofing through approval and monitoring. That approach also supports later review if regulators or auditors ask why a customer was accepted under remote onboarding conditions. In Mexico-specific deployments, the challenge is usually not lack of checks, but inconsistent application across products and channels, which creates gaps in both compliance evidence and operational resilience. The FATF Recommendations — AML and KYC Framework remain the clearest reference point for risk-based customer due diligence expectations, while local procedures must determine how those principles are operationalised.

Related resources from NHI Mgmt Group

• How should security teams implement customer due diligence without creating too much onboarding friction?
• How should security teams govern non-doc verification in customer onboarding?
• How should security teams assess a vendor’s ownership claims during due diligence?
• What should compliance and security teams do when fraud risk affects investor due diligence?