KYC Pre-built Form

The KYC Pre-built Form allows you to collect identity verification information from customers without building your own verification interface.

Instead of building a custom onboarding UI, you generate a secure session link and direct the customer to the pre-built form. Nium manages document collection, identity verification, and compliance checks based on regional regulatory requirements.

The KYC pre-built form is the recommended identity collection method for Customer Onboarding v5.

What the KYC pre-built form does

The form manages the identity verification workflow for your onboarding process.

Using the pre-built form:

• Customers provide identity details through a guided verification flow.
• Nium determines required documents based on region and configuration.
• Identity verification may occur instantly or through manual document review.
• Verification results update the customer's onboarding status.

This approach allows you to integrate onboarding without building and maintaining your own KYC interface.

When to use the pre-built KYC form

Use the pre-built form if you:

• Do not want to build and maintain your own KYC interface
• Want Nium to manage region-specific document requirements
• Want a branded onboarding experience
• Want automated verification where available

How it works

The KYC verification workflow follows these steps:

1. Create a session using the Create Session API.
2. Generate a form link using the returned sessionId.
3. Share the link or embed the form in your application.
4. The customer completes identity verification.
5. Nium processes verification checks.
6. The customer's onboarding status and substatus update accordingly.

You can retrieve the latest status using the Get Customer Details API or subscribe to Customer Lifecycle webhooks.

Responsibilities

When using the KYC pre-built form:

• Nium manages document collection and identity verification.
• Nium determines document requirements based on region and configuration.
• The client is responsible for initiating onboarding and generating sessions.
• The client controls when the onboarding process begins.

Branding

You can provide a company logo to display on the pre-built form.

If no branding is provided, the default Nium logo is displayed.

Contact your Nium account representative or Nium Support to configure form branding.

---

Integrating pre-built forms

Step 1: Provide branding assets (optional)

Share your company logo with your Nium account representative or Nium Support.

If no logo is provided, the Nium logo appears in the form.

Step 2: Create a session

Create a session to generate a sessionId.

Example request

curl --location 'https://gateway.nium.com/api/v1/client/{clientHashId}/sessions' \
--header 'Content-Type: application/json' \
--header 'x-api-key: ***********' \
--data '{
  "featureType": "kyc_form",
  "integrationType": "standalone",
  "expiry": "2026-02-25T10:30:00Z",
  "rollingDurationMinutes": 200,
  "onBehalf": false,
  "customerHashId": "549d0fd0-d5f1-411f-85a3-q19cbfd310r4"
}'

Request parameters

Field	Type	Required	Description	Allowed values
featureType	string	Yes	Type of form to generate.	kyc_form
customerHashId	string	Yes	Unique customer identifier returned from the Create Customer (v5) request.	—
integrationType	string	Yes	Determines how the form is presented to the user.	embedded, standalone
expiry	string (ISO-8601)	Yes	Absolute expiration time for the session.	—
rollingDurationMinutes	integer	Yes	Inactivity timeout before the session expires. Minimum value: 1.	—
domain	string	Conditional	Required when integrationType = embedded. Must match the session domain.	—
onBehalf	boolean	Yes	Indicates whether the client accesses the form on behalf of the customer.	true, false
email	string	Conditional	Required when onBehalf = true. Used for OTP authentication.	—

• expiry defines the absolute expiration time of the session.
• rollingDurationMinutes defines how long the session remains active during inactivity.

Step 3: Present the form

Append the generated sessionId to the form URL.

https://nformify-sandbox.nium.com/kyc?sessionId=

You can present the form in two ways:

Integration type	Description
embedded	Displays the form within your application or dashboard.
standalone	Opens the form in a new browser tab.

Step 4: Customer accesses the form

The authorized signatory opens the form link.

If authentication is required, an OTP is sent to the configured email address.
The user must enter the OTP to proceed.

Step 5: Customer completes KYC

After authentication, the customer completes identity verification.

The form displays:

• The list of individuals requiring verification
• Required documents based on region and stakeholder role
• Real-time verification status updates

The user must complete KYC for:

• The authorized signatory
• Any additional stakeholders specified during onboarding

Depending on configuration:

• Verification may complete instantly through automated checks
• Documents may be uploaded for manual verification

---

Verification status updates

Customer verification status changes as KYC progresses.

Before KYC submission

Field	Value
status	pending
substatus	awaiting_kyc

During verification review

Field	Value
status	pending
substatus	under_review

After verification completes

The customer status updates based on the verification outcome.

Examples include:

• clear
• rejected

You can retrieve the latest verification status using:

• Get Customer Details API
• Customer lifecycle webhooks

---

Session expiration

If a form session expires:

• The form link becomes invalid.
• A new session must be generated.
• Previously submitted information remains associated with the customer.

Multiple sessions can be generated for the same customer if needed.

---

Retrying verification

If a user does not complete the form:

• The session expires based on expiry or rollingDurationMinutes.
• A new session can be generated.
• Previously submitted information remains associated with the customer.

If verification fails:

• The customer's KYC status updates accordingly.
• A new session may be required depending on the failure reason.