KYC and customer-onboarding policies

Open Business Configuration → Workflow Configurations → Customer. The Customer group contains KYC Policies and Customer Onboarding Policies.

A KYC Policy defines the facts, checks, and evidence required for a kind of customer. A Customer Onboarding Policy connects a Customer Type to a compatible KYC Policy and Customer Onboarding Workflow Definition.

Access and lifecycle

KYC Policy and Customer Onboarding Policy have separate entity permissions. For each, Read shows records, Create permits a new draft, Update permits eligible draft changes, Delete controls supported deletion or restoration, and L1, L2, and L3 authority controls the matching checker step.

Both policy types use maker-checker for initial creation. KYC Policies also support amendments after authorization: the active policy remains effective until its amendment is authorized.

Customer Onboarding Policies currently do not support amendments. An Authorized policy cannot be edited or deleted from its detail page. Customer applications retain the policy selected when they start, and later approval and customer creation checks continue to use that policy's group and related-party rules. Keeping the Authorized policy immutable prevents an in-flight application from being judged against rules that changed partway through its journey.

At L0, select the target company when creating either policy. Tenant users are fixed to their own company.

Create a KYC Policy

Open KYC Policies, select Create KYC Policy, and enter its Code, Name, and optional Description. Select a Customer Kind to restrict the policy to Individual, Corporate, or Group, or leave it unrestricted for all compatible kinds.

Configure KYC data requirements

Data requirements identify customer facts that must or may be captured. For each row, select the canonical fact, mark whether it is required, assign its sort order, and optionally add applicability conditions.

Conditions within one group use AND. Alternative groups use OR. The available condition facts include baseline, customer type, sector, and industry.

If one requirement's applicability depends on another fact, that driver fact must itself be an unconditional required data requirement. Baseline is the exception because it represents an unconditional path.

Configure KYC checks

Add the checks that must be evaluated for an application. Check types include Identity, Contact, Address, Source of Funds or Wealth, Risk, Beneficial Owner, PEP, Sanctions, Tax ID, and Biometric checks.

For each check, configure its unique label, required state, severity, waivability, verification mode, execution mode, sort order, evidence capture, and any applicability conditions.

• Blocking checks must be satisfied or validly waived before progress;
• Advisory checks record information without blocking by themselves;
• a Manual check that requires a decision must use a verification mode other than None;
• Automatic checks use None because no manual verifier is expected;
• in the current form, only Contact Completeness offers Automatic execution; the other selectable check types are Manual;
• a required Blocking Identity check must use Existing Identity evidence.

Choose the Evidence Capture mode by the source the operator must confirm:

Evidence Validity limits how long captured evidence remains reusable. When valid evidence expires, is removed, or no longer matches its source, the check returns to Pending before the KYC evaluation can pass.

For Existing Customer Fact, choose a fact that is available on the customer application. The capture screen does not let the operator retype or override it. Correct the application fact first when the displayed value is wrong.

Submit and authorize KYC

Before authorization, the policy must contain at least one required active check and at least one unconditional required active check. Submission and authorization revalidate requirements, conditions, checks, and evidence rules.

Create a Customer Onboarding Policy

Open Customer Onboarding Policies and select Create Customer Onboarding Policy. Enter its code, name, and optional description, then link:

• an active Customer Type;
• an active Authorized KYC Policy compatible with the Customer Type's category;
• an active Authorized Workflow Definition whose Owner Type is Customer Onboarding.

Choose whether this is the Default Policy for the Customer Type. Only one Authorized default may exist for the same tenant and Customer Type. When users do not explicitly select a policy, remoteEaze uses the default; if several policies apply and none is the default, the intended policy must be selected.

Set Customer Creation to automatic creation on workflow approval or manual creation after approval. This controls when the approved application becomes a live customer record.

For a Group Customer Type, configure how group members are resolved and the minimum and maximum member counts. Configure any required related-party roles, including label, subject mode, minimum and maximum counts, and whether identity, contact, address, or ownership information is required.

Submit the policy and complete its required approvals. Authorization checks that all linked records remain active and Authorized, that the KYC Policy is compatible with the Customer Type, and that the Workflow Definition has the correct owner type.

If a draft policy was deleted, restoration is allowed only while its linked Customer Type, KYC Policy, and Workflow Definition still meet those dependency rules.

Complete the verification steps in Before onboarding the first customer before using the policy for live applications.