remoteEaze

Authorize an application and create the customer

How authorization produces the customer record and optional account.

Customer-application approval is the configured workflow's Approve business outcome. It is not a separate L1, L2, or L3 maker-checker action. The approving transition validates the entire onboarding result and either creates the live Customer automatically or makes Complete Onboarding available afterward.

Access required

The user advancing the approving transition needs Process Workflow, access to the application, and an accepted current-stage assignment. The transition and any applicable CREATE_CUSTOMER action must be Authorized and allowed by their runtime rules.

For manual creation, Complete Onboarding also requires Process Workflow. Normally, only the user who completed the approving workflow stage can perform this final action. L0 and Tenant Administrator capabilities provide the administrative override.

Approval checks

Before an Approve transition completes, remoteEaze requires:

  • a terminal target stage;
  • KYC status Passed or validly Waived;
  • every blocking workflow requirement across the application to be resolved;
  • the current stage's assignment, review gate, and transition outcome to be valid;
  • every related-party role to meet its policy counts, subject mode, and required information;
  • every Group member to meet the policy's count and resolution mode;
  • an applicable Authorized CREATE_CUSTOMER action on the approving transition when the policy uses automatic creation.

If any check fails, the transition stops without treating the application as approved. Complete or correct the named control, then retry the permitted workflow action.

Before writing the live Customer, remoteEaze also confirms that the finalized KYC attempt belongs to the current Authorized version of the selected KYC Policy, that required identity evidence is present, and that every related party or Group member routed through a child application has produced its Customer. In manual mode, these final checks can leave the application Approved while Complete Onboarding remains blocked. Restart KYC or complete the linked applications as indicated.

Automatic creation on approval

When the Onboarding Policy uses Automatic on Approval, select the approving path in Advance Stage. The CREATE_CUSTOMER action must be bound to that approving transition.

In one controlled operation, remoteEaze completes the workflow, marks the application Approved, creates the Customer, and changes the application to Customer Created. The resulting Customer is Authorized and Active and carries the application's final KYC status.

Manual creation after approval

When the policy uses Manual after Approval, the approving transition completes the workflow and leaves the application Approved.

At the approved stage, select Complete Onboarding. The button appears only when the stage has an applicable Authorized CREATE_CUSTOMER action, no Customer has already been created, and KYC is Passed or Waived. remoteEaze rechecks all blocking requirements and composition rules before creating the Authorized, Active Customer and setting the application to Customer Created.

Customer creation is idempotent: if the application already has its Customer, the existing result is retained rather than creating another Customer.

Optional Account post-action

If the applicant requested an Account and an applicable CREATE_CUSTOMER_ACCOUNT action was frozen at submission, remoteEaze runs it after the Customer exists. The Account uses the selected Product, Currency, optional Account Condition and Account Name, and the Branch, Relationship Officer, and Agent carried by the application.

The Account Request tab shows the applicant decision, frozen approval result, execution attempts, created Account, and any failure. The result can be:

  • Account Authorized when the frozen approval count is zero;
  • Account Pending Approval when the created Account must complete its own maker-checker approvals;
  • Failed Retryable when no Account was created and a technical or reference problem prevented the action from completing;
  • Account Created with an error when the Account exists but its submission or authorization step did not complete.

An Account awaiting approval follows the Account's maker-checker lifecycle and requires the relevant Account authorization authority. This does not reverse the already-created Customer.

For a retryable failure, a user with Process Workflow can select Retry Account Action after correcting the cause. Retry is limited to the technical states presented as retryable; it is not a way to change the applicant's frozen choice or approval result.

Other terminal outcomes

  • Rejected: the workflow rejected the application and no Customer is created.
  • Closed: the workflow closed the application and no Customer is created.
  • Returned for Correction: the applicant data can be corrected and resubmitted; this is not a terminal rejection.
  • Withdrawn: a Draft was closed before submission.

After successful creation, use Open Customer from the application or open the Customer from Customer Relationship → Customers. If an Account was created and you have Read Account, select Open with its account number from the Account Request tab.

On this page