eKYC in South Africa: FICA Requirements for Remote Onboarding

A customer can pass a document check, a selfie comparison and a sanctions search, and the institution can still be left with an onboarding decision it cannot defend. What usually goes missing is a rule: why those checks were enough for this customer, what happened when they disagreed, and who accepted the residual risk.

South Africa's Financial Intelligence Centre Act does not prescribe a selfie workflow for eKYC. It requires an accountable institution to establish and verify identity with enough confidence for the money-laundering and terrorist-financing risk it has assessed. So remote onboarding has to be built as an executable part of the institution's Risk Management and Compliance Programme (RMCP). A vendor feature list does not do that job.

In brief

• eKYC is a delivery channel for customer due diligence (CDD). It does not create a separate compliance standard.

• The RMCP should connect customer type and risk to required information, independent evidence, approval authority, exceptions and ongoing review.

• Document analysis, authoritative-source checks, face matching and liveness answer different questions, and no control should quietly stand in for another.

• A sanctions or PEP result feeds a documented decision. On its own it is no legal conclusion.

• If required CDD cannot be completed, section 21E restricts starting or continuing the relationship and requires consideration of a section 29 report.

• An audit record should let someone reproduce the decision. KYC passed is not enough.

What FICA requires—and what it leaves to the institution

FIC Guidance Note 7 separates two operations. Establishing identity means obtaining the customer's particulars. Verifying identity means corroborating them against documents or electronic data from reliable and independent third-party sources. The guidance says the nature and extent of verification should follow the institution's assessment of ML/TF risk.

The flexibility is real, but it is controlled. Section 42 requires the institution to maintain an RMCP. FIC Public Compliance Communication 53 says its CDD controls should address prospective and existing clients, beneficial owners and representatives; risk-based levels of verification; enhanced and simplified due diligence; onboarding approval; ongoing due diligence; and the process when CDD cannot be completed.

Keep three layers apart:

A vendor threshold is a setting in a product. The board approves the policy, and an interface response only reports one check. Merge the layers into one undocumented “pass” flag and neither a compliance review nor a model change can be done safely.

Turn the RMCP into a remote-onboarding decision table

Policy prose is hard to apply the same way every time. For each permitted remote journey, translate the RMCP into a version-controlled decision table.

Each row should define at least:

• Scope: customer type, product, channel, jurisdiction and whether the person acts for someone else.

• Information: the fields to establish, including beneficial-owner and representative data where applicable.

• Evidence: acceptable documents and independent sources, their freshness and required field matches.

• Holder binding: how the institution links the evidence to the remote presenter.

• Financial-crime screening: which sanctions, targeted-financial-sanctions, PEP and other risk sources are checked, and when.

• Decision: pass, reject or refer conditions, approval authority and maximum review time.

• Fallback: permitted alternative evidence, retry limits and accessibility route.

• After onboarding: monitoring triggers, data-refresh interval and re-verification conditions.

The table guards against a familiar failure, where a fallback meant for low-risk cases turns into a bypass for everyone. If an authoritative source contradicts the claimed identity, asking for the same document again resolves nothing independently. The exception has to either obtain stronger evidence or go to a reviewer authorised for that case.

Design evidence as a chain, not a pile of checks

A remote process usually needs several controls, each with a defined scope. Which ones you combine depends on risk and on which sources are available.

Document capture and analysis extract claimed data and test supported document features. They do not prove that a genuine document belongs to the presenter.

Independent-source corroboration compares claims with a reliable external source. Confirm access, coverage, matching fields and what each response means. A provider should not suggest it can reach every government database.

Face matching estimates similarity between the presenter and a trusted portrait. Liveness and capture-integrity controls address covered presentation or injection attacks. Neither establishes the reliability of the reference image.

For the detailed trade-offs, including Home Affairs verification routes and cost drivers, see Identity Verification in South Africa: Methods, Home Affairs and Cost.

Counting green ticks tells you little about evidence strength. Two OCR tools reading the same uploaded image still depend on one source. A stronger chain asks different questions. Is the credential plausible? Does an independent source corroborate the information? Is the presenter linked to the reference? Does the capture look like a live session?

Screening must preserve the reasoning behind the result

Resolve identity first, close enough to screening that you are not searching unstable or incomplete names. Screen the resolved person and, where required, beneficial owners and representatives. Keep the aliases, the transliteration choices, the date of birth or registration details and the list version you used.

South Africa's Targeted Financial Sanctions portal publishes notices that change and data you can download. A cached list with no update time leaves a hole in your evidence, so record the dataset version and the trigger for re-screening.

A fuzzy name match does not confirm a designation. You need rules for clearing false positives, escalating plausible matches, avoiding premature disclosure and recording why the reviewer decided as they did. AML Screening Biometric.Vision can sit inside a broader eKYC flow for screening and repeat monitoring; the institution still configures sources, thresholds and review, and makes the reporting decisions.

Treat inconclusive as a real outcome

Binary automation invites bad conversions. Poor image quality turns into “not matched,” an unavailable source into “no issue,” a timeout into “retry until pass.” Use at least three operational outcomes:

Section 21E of the FIC Act booklet states that when required CDD cannot be performed, an accountable institution may not establish the relationship or conclude the relevant transaction, and must act on an existing relationship as its RMCP requires. It must also consider a report under section 29. In practice, a “manual review pending” status must never open an active account by default.

Store a decision that can be reproduced

From the audit trail you should be able to tell what the institution knew at the time and which rule it applied. Subject to applicable data-protection and retention controls, keep:

• claimed identity data and the customer or representative role;

• evidence type, issuer or source, response and collection time;

• consent or other applicable processing basis where relevant;

• model and ruleset versions, thresholds and quality signals;

• sanctions and PEP datasets, query values and candidate dispositions;

• automated outcome, exception route, reviewer, reason and timestamps;

• the RMCP version and decision-table row that authorised the result.

Sections 22 and 23 impose recordkeeping duties, generally for at least five years from termination of the relationship or completion of a transaction, as explained in FIC PCC 02. That is no reason to keep every intermediate biometric artefact for five years by default. Design the records and access controls around compliance, privacy, security and what you will need as evidence.

Onboarding is the first decision, not the last

Section 21C of the FIC Act requires ongoing due diligence. The eKYC design should pass verified attributes, risk factors and confidence limits on to monitoring instead of reducing the customer to approved=true.

Set event-driven refresh triggers: an expired credential, a change in beneficial ownership, returned contact data, a new PEP or sanctions signal, unusual activity, account recovery, a material product change, or doubt about information you already hold. Section 21D requires repeated CDD steps where the veracity or adequacy of earlier information is in doubt or a suspicious report is made.

Biometric.Vision Orchestrator can coordinate document, biometric and screening components into a conditional workflow. Keep the institution’s RMCP rules, evidence provenance and approval authority visible in that workflow; a single provider score should not hide them.

Questions to answer before launch

• Which RMCP row covers every remote customer and product combination?

• Which source independently corroborates each material identity claim?

• What does each score prove, and where does its proof stop?

• Can a timeout, retry or fallback weaken a failed control?

• Who may clear a sanctions candidate or approve a high-risk relationship?

• Can an auditor reproduce the decision using stored versions and evidence?

• Which events trigger re-screening, data refresh or re-verification?

• What happens technically when section 21E prevents completion?

If an answer lives only in a vendor demo or in one operator's head, your remote journey is not yet a controlled eKYC process. Test it this way: the same risk and evidence should produce the same decision, one you can explain, and every exception should stay visible and under governance.