KYC Requirements for Egyptian Banks: A Customer Verification Guide

A genuine Egyptian ID can be handed over by the wrong person. A company can be correctly identified and still hide who controls it, and a customer verified at onboarding can turn high-risk a year later. None of these are edge cases. They are the reason bank KYC works as a continuing decision process rather than a document-upload screen.

Egypt's banking AML/CFT framework places banks under Central Bank of Egypt supervision and uses a risk-based approach. The customer file must connect identity evidence, beneficial ownership, expected activity, screening, acceptance authority and monitoring. Digital Financial Identity changes how a bank obtains some of that evidence. The obligations stay separate, and one platform response does not discharge all of them.

In brief

• KYC establishes who the customer and relevant natural persons are; CDD adds risk understanding, acceptance and ongoing monitoring.

• A natural-person file and a legal-person file need different evidence and decision paths.

• The beneficial owner is the natural person who ultimately owns or controls the customer or on whose behalf a transaction is conducted.

• Screening must run on resolved identities and keep the reasoning behind each candidate review, beyond a bare “clear” flag.

• The bank needs a reproducible acceptance decision with the applied policy and evidence versions.

• Onboarding sets the baseline. Identity and risk information must be updated whenever the relationship changes.

Start with the decision, not the form

The CBE's compliance guidance describes CDD as identifying the customer and verifying identity using reliable, independent documents, data or information. It includes beneficial owners, a customer risk profile, acceptance policies, maintained customer information and ongoing transaction and relationship monitoring.

The CBE's AML/CFT supervision page says its fundamental supervisory framework is risk-based. In practice, the KYC process has to end in a risk decision someone can explain. Running the same checklist for every customer does not meet that bar.

A useful design separates four questions:

The form feeds the process. What comes out should be a governed decision that a second reviewer could reach again from the same file.

Build different files for people and organisations

For a natural person, establish the data required by the bank's current policy: name, identity or travel-document details, date of birth, nationality, address or contact information, occupation and the purpose and expected nature of the relationship. Take the exact fields and acceptable evidence from applicable CBE rules and the bank's approved policy; a generic global template is the wrong source.

Record the source and result for each material claim. Document extraction, document-authenticity signals, database corroboration, face comparison and liveness are separate controls, and each needs its own entry. If a source is down, log the check as “unavailable”; it was never “verified.” A high face similarity score says nothing about whether the reference credential itself is genuine.

A legal-person file needs much more than an image of the commercial registration. Establish the legal name, form, registration, address, activity, authority to act, ownership and control structure, and the natural persons who ultimately control the customer. Verify the entity through accepted independent sources and verify representatives separately.

The CBE's compliance page defines a beneficial owner as the natural person who ultimately owns or controls the customer, the person on whose behalf a transaction occurs, or a person exercising ultimate effective control over a legal person, entity or arrangement. Where control is indirect, contractual or spread across several layers, a shareholder list alone may not show it.

Create an ownership map with evidence at each edge: entity, jurisdiction, percentage or control basis, source, date and verification status. Do not stop at another company. Resolve the chain to natural persons or follow the approved escalation where no person can be established under the applicable rules.

Use a KYC decision ledger

Long after onboarding, the bank should still be able to reconstruct why it accepted a customer on a given date. A decision ledger keeps identity, risk and authority together, with the provenance of each visible.

For every material control, store:

• subject and role: customer, representative, beneficial owner or related party;

• claimed value and normalised value;

• evidence source, document or dataset version;

• request time, response and quality or confidence information;

• rule applied, outcome and reason code;

• reviewer and approval authority where human judgement occurs;

• next review date or event-driven refresh trigger.

A PDF “KYC pack” assembled after the event cannot do this. With structured provenance, a change to a source, threshold, list or policy lets the bank pull up every decision it touched.

Risk profiling needs causal factors

Nobody should have to guess where a risk tier came from. Keep the factors behind it: customer type, ownership complexity, geography, product, delivery channel, expected volumes, source of funds or wealth where applicable, PEP exposure, adverse information and other factors in the bank's methodology.

Risk factors set how deep due diligence goes; on their own they prove no suspicion. High risk may require enhanced evidence, senior approval, tighter limits or more frequent review. A possible name match requires investigation. An unusual expected activity needs an explanation and corroboration appropriate to the case.

Keep policy risk and model risk distinct. If a scoring engine changes, the bank should know which customer tiers move and why. Version the factor weights, cut-offs and override permissions. Watch override rates by reviewer and by reason. Routine manual exceptions can hollow out a policy that looks strong on paper.

Screening is identity resolution plus judgement

Screen only after names and relevant identifiers are normalised. For individuals, preserve aliases, Arabic/Latin transliterations, birth data and nationality where available. For entities, include trade names, former names, registration details and resolved beneficial owners.

AML Screening Biometric.Vision can screen individuals and organisations against supported sanctions, PEP and other stated sources, support repeat monitoring and retain workflow results. The bank must still confirm source coverage and freshness, configure matching, define who may clear or escalate a candidate, and decide regulatory reporting.

A screening record should show the query, list version, candidates returned, identifiers compared, disposition and rationale. “No hit” without those details cannot show whether the right person, spelling or current list was checked.

Do not tip the customer off. The CBE compliance guidance explains that a customer should not be told that an account is monitored, that a transaction is considered suspicious or that information has been sent to designated authorities. Write decline messages and support scripts with that in mind: they may say only what policy and law permit.

Digital onboarding changes capture, not accountability

The CBE's 2026 Digital Financial Identity framework covers electronic identification, verification and information updates for individual customers through the approved platform. It also covers consent, authentication and identity sharing.

That service architecture is explained in Egypt's Digital Financial Identity: How the eKYC Platform Changes Onboarding. For bank KYC, a platform event can supply identity evidence. The bank's CDD workflow still has to combine that evidence with risk, screening, product rules and approval.

Biometric.Vision Orchestrator can coordinate document, biometric and screening components in a conditional flow. It should not be presented as connected to the CBE platform unless participation and integration are specifically confirmed.

Failed, incomplete and contradictory cases need explicit routes

Use at least three operational outcomes: approved, referred and stopped. “Pending” must not silently grant product access.

Define which missing field can be completed later, which required evidence blocks activation and which contradiction triggers investigation. Limit retries. One more selfie request helps a genuine customer past a blurry capture. Unlimited requests give an attacker unlimited attempts. Preserve the sequence of attempts and changes in identity data.

Manual reviewers need permitted evidence, conflict-resolution rules, escalation authority and quality assurance. Show them why automation referred the case, along with the final score. Measure false referrals, overturned decisions and recurrent exception reasons. Weak capture and weak policy design show up there first.

Keep the file alive after approval

The CBE describes ongoing maintenance of customer and beneficial-owner information and transaction monitoring as part of CDD. Define both scheduled review and event triggers, such as:

• an expired or replaced identity document;

• a changed address, phone, representative or beneficial owner;

• product or expected-activity changes;

• a new sanctions, PEP or adverse-information candidate;

• activity inconsistent with the recorded profile;

• account recovery or suspected identity compromise;

• doubt about previously obtained information.

Records should connect the old value, new evidence, effective time and approving rule. The CBE's compliance guidance states that transaction, customer, beneficial-owner, identification, risk-analysis and monitoring records must be retained for a minimum of five years unless another policy or law requires longer. Apply current legal, privacy and security requirements to determine precise retention and access for each artefact.

Pre-launch control test

• Can the bank identify every person whose identity or authority matters?

• Does every material claim have independent evidence and a recorded source?

• Can ownership be traced through entities to natural persons and control?

• Are risk factors visible separately from the final tier?

• Can reviewers explain every screening disposition and override?

• Does an unresolved mandatory check prevent activation?

• Can a rule or list change identify affected customer files?

• Are monitoring and refresh triggers connected to the original profile?

A KYC file is complete only for the decision and the date it supports. An Egyptian bank's process has to keep that context attached: who was verified, through which source, against which risks, under which policy, and which event or date triggers the next review.