Digital identity in Morocco: where the CNIE ends and customer KYC begins
A practical boundary map for the Moroccan CNIE, Mon Identité Numérique, authentication and a service provider's customer decision.
A scan of a Moroccan CNIE, a login approved through the national digital-identity service and a business decision to open a product are three different events. The scan is an image of a credential. The login confirms one operation inside the state identity environment. The product decision applies the provider's own KYC and risk rules. Collapse all three into a single identity_verified flag and you can no longer tell which one happened.
Moroccan Law No. 04-20 provides that the electronic national identity card certifies the holder's identity, including digital identity, through a unique national identity number. A customer holding a CNIE does not turn a private onboarding flow into part of the state system, and the business keeps its own controls.
The four layers that should remain separate
Layer | What it contributes | What it does not decide |
|---|---|---|
CNIE | State identity credential and machine-readable security means | How the presenter and credential are checked in this session |
National e-ID | Holder-controlled authentication and attribute sharing | Why a service needs those attributes |
Service-provider flow | Connects the e-ID response, product and other checks | Whether residual risk is acceptable |
KYC decision | Approves, limits or refuses the relationship | Future monitoring and evidence retention |
Record each signal as what it is, and never upgrade it. A photograph of a CNIE tells you nothing about the chip. A successful authentication leaves beneficial ownership unanalysed. Consent to release an attribute covers the purpose it was given for, and later uses need their own basis.
What the CNIE establishes
Articles 1 and 3 of Law No. 04-20 connect the CNIE to the holder's identity and digital identity and describe an encrypted electronic chip, a machine-readable zone and digital security certificates generated by the DGSN and uniquely linked to the card and holder.
That gives three evidence modes, and the record should name the one used: visual or OCR processing of a card image, reading the machine-readable data, or protected chip interaction with cryptographic verification. If your system only extracted printed text, it has no grounds to record “CNIE cryptographically verified”.
Mon Identité Numérique is a transaction channel, not the customer's entire file
The official Identité Numérique portal describes Mon Identité Numérique as the national application backed by the CNIE for proving identity online or face to face. Use of the portal and application is optional, and the setup page connects initial validation to an NFC-capable phone.
According to the official service description, the holder approves requests on the associated phone, can use device biometrics to unlock the card and releases information to a service provider after consent. The portal states that attributes are sent directly to providers and not stored centrally within the described flow. Those are the official service's own statements about its design. They say nothing about what each participating provider does with the data downstream.
In May 2026, the official government portal also announced a forthcoming digital card in the Mon e-ID application. “Forthcoming” does not mean generally available. Production documentation should record the app version and the route that actually existed when you implemented it.
Authentication does not complete customer due diligence
An e-ID response is strong evidence that the holder approved a particular operation. The service provider still determines whether the response belongs to the same session and product, whether the released attributes are sufficient and current, whether the person acts for themselves or a principal, whether ownership or AML checks are required, and which channel or behaviour risks remain.
The same state authentication may be proportionate for logging in to an existing account and still fall short for opening a new regulated relationship. Use e-ID as an authoritative input to KYC, and keep the rest of the KYC process around it.
Device biometrics and a provider's Face Match are not the same control
Device biometrics may unlock a local action without disclosing a biometric template to the service provider. A separate face comparison processes images in the provider's workflow and creates a different data operation and evidence object.
Biometric.Vision Face Match can estimate similarity between a current image and a selected reference portrait. Liveness can evaluate live-presentation properties within the tested attack scope. Neither product reads the CNIE chip, returns an official DGSN response or accesses Mon Identité Numérique, and nobody should describe them that way unless a project-specific integration has been confirmed technically and contractually.
Before you add a selfie, name the uncertainty it resolves. If the official path already gives enough evidence for the purpose, extra biometrics mostly add sensitive processing. If presenter binding is required, the reference source, threshold, exception route, retention and error consequences need explicit design.
Personal-data controls follow purpose, not the onboarding screen
Law No. 09-08 covers collection, recording, storage, use, disclosure, matching, blocking, erasure and destruction of personal data. The CNDP formalities page explains that processing generally requires the appropriate prior formality unless excluded, exempted or subject to a different authorisation regime; foreign transfers are assessed separately.
Purpose | Evidence to retain |
|---|---|
e-ID attribute request | Requested fields, recipient, legal basis, consent event and response |
Face verification | Images, reference, model, threshold, exception and retention |
Fraud prevention | Device and behaviour signals, access and decision effect |
KYC/AML | Applicable rule, risk profile, decision and review trigger |
Authentication | Factor, device, event, revocation and recovery route |
The CNDP publishes sample notices for particular facial-recognition scenarios, including remote-account processes at banks and payment institutions. You cannot paste a sample into a different product as is; first align the purpose, controller, formality and actual data flow.
A reproducible service-provider workflow
Define the action first: authentication, registration, product opening, signature or data refresh.
Select the official or private source and document its exact role.
Give each attribute request a transaction ID, purpose, timestamp and user approval.
Preserve the source response separately from OCR, Face Match, liveness and fraud signals.
Route discrepancies without silently overwriting the original value.
Store the final rule, version, decision owner, exception and next review trigger.
Biometric.Vision Orchestrator can connect available document, face, liveness, AML and manual-review steps in a versioned workflow. It has no implied connection to the CNIE, DGSN or Mon Identité Numérique. Any such link would have to be set up separately, with its own technical, contractual and legal scope.
“Was identity verified?” is too coarse a question for a regulated provider. A well-built flow records which source confirmed which attribute, which action the holder approved, which uncertainty each control addressed and who accepted the final risk.
Sources
Ready to strengthen your customer checks?
500 checks free every month · no card · no contract · no sales call.
