Complete customer data, KYC, and requirements

Customer information is collected in two places: eligible initiation fields are corrected while the application is Draft or Returned for Correction, while KYC facts, evidence, related parties, Group members, and workflow requirements are captured at the stages configured to collect them.

Access required

You need Read Customer Application and access to the application. Update Customer Application permits application corrections and operational capture. Work attached to a workflow stage also requires an accepted current- stage assignment and the corresponding authorized stage action.

Ordinary verification decisions require Process Workflow. A waiver requires Waive Customer Application, a control configured as waivable, and a reason.

Open the application

Open Customer Relationship → Applications, then select the application reference. The detail screen contains these tabs:

Overview: lifecycle milestones and the created Customer, when present;
Customer Details: collected facts, identities, related parties, and Group members;
Account Request: applicant choice and the frozen Account decision, when the workflow makes this option available;
KYC: policy facts, checks, evidence, current outcome, and attempt history;
Workflow: current stage, requirements, assignments, reviews, and history;
Admin: application reference, audit actors, and update time.

Correct a Draft or returned application

Open Actions → Edit Application. This action is available only for a Draft or Returned for Correction application without a created Customer.

The editable initiation data includes the customer's name, contact details, Branch, Relationship Officer, Agent, applicable sector and industry, and the Account request. The Customer Type and Onboarding Policy remain fixed. Capture new workflow-required information through the KYC or Workflow controls instead of trying to change the initiation record.

Changing Branch clears branch-dependent assignments and Account selections. Review every dependent field before saving. When a returned application is corrected, use Actions → Resubmit Application to restart processing.

Complete KYC data and checks

KYC can be operated only at a stage with an applicable authorized EVALUATE_KYC action.

Accept or self-assign the current stage.
Open Actions → Start KYC. This creates the active attempt, builds the policy worklist, and runs automatic checks.
On KYC, capture any missing required facts. Applicability conditions can make a fact required only for a particular customer kind, branch country, sector, or industry.
For each item under Pending Manual Work, select Capture and provide the evidence required by the policy. Depending on the check, this can be an existing identity, document, structured value, observed value, or manual attestation.
When evidence needs a decision, select Verify, then record Passed or Failed. Use Waived only where the check permits it and enter the reason.
Select Actions → Evaluate KYC to finalize the attempt against the current facts and check decisions.

If a finalized attempt needs to be run again, Actions → Restart KYC creates a new attempt using the latest applicable policy information. Unchanged valid evidence can be reused, and the earlier attempt remains under Previous Attempts.

An independent-actor check cannot be verified by the user who captured its evidence. The final outcome must be Passed or validly Waived before an approval transition or Customer creation can complete.

Complete workflow requirements

Open Workflow → Requirement Results. The current stage can contain Data Field, Document, Computed Rule, Approval, or Review requirements.

Select Capture or Recapture to record an eligible result. A blocking Document requirement must include its uploaded evidence.
A requirement whose verification mode is None is satisfied when its result is Captured.
For other verification modes, select Verify after capture and record Approved or Rejected.
A configured waivable requirement can instead be Waived by a user with Waive permission who provides a reason.
Independent Actor Required prevents the capturing user from verifying the same result.

A blocking requirement prevents its stage from advancing until it is Captured when no verification is required, or Verified or Waived otherwise. Approval and Customer creation also check every blocking requirement across the workflow, not only those on the final stage.

When the current stage has CAPTURE_RELATED_PARTIES or LINK_GROUP_MEMBERS, the corresponding button appears on Customer Details.

For related parties, follow the Onboarding Policy's role, minimum and maximum counts, subject mode, and required identity, contact, address, and ownership information. A policy can require a link to an existing Customer or to another Customer Application instead of allowing an inline subject.

For a Group application, each member must follow the configured resolution mode. Where child applications are allowed, an unresolved member offers Start Child Application. Approval validates the configured counts and resolution mode. Customer creation additionally requires every related party or Group member resolved through a linked application to have produced its Customer.

Continue with Assign, review, and progress an application.