Skip to main content

Overview

The Individual module manages individual identity verification (KYC). It provides methods to collect, update, and submit personal information for verification including name, date of birth, documents, addresses, and consents.

Accessing the Module

The Individual module is accessed through the SDK context after initialization:

Module Options

When initializing the SDK, you can configure how much detail the Individual module retrieves from the API:

IndividualLevel

Controls the level of detail retrieved for entity data, particularly document scans: Default: If not specified, uses the default level configured by FrankieOne.

State Management Methods

isLoading()

Returns whether the module is currently performing an async operation (search, submit, etc.). Signature:
Returns: boolean - true if loading, false otherwise Description: Indicates if the module is actively fetching or submitting data. Set to true at the start of search() or submit() calls, and false when completed. Example:

isPreloaded()

Returns whether existing entity data was found and loaded. Signature:
Returns: boolean - true if existing data was loaded, false if starting fresh Description: After calling search(), this indicates whether the entity already exists in the system with existing verification data. true means you’re continuing an existing verification; false means this is a new entity. Example:

isPersisted()

Returns whether all changes have been submitted to the server. Signature:
Returns: boolean - true if all data is saved, false if there are unsaved changes Description: Whenever you make changes to the individual’s data (name, documents, addresses, etc.), this flag is set to false. After successfully calling submit(), it’s set back to true. Use this to track whether there are pending changes. Example:

Data Fetching Methods

Searches for and loads existing entity data from the server. Signature:
Returns: Promise<void> - Resolves when search completes Description: Queries the server for any existing data associated with the current session’s entity. If data exists, it’s loaded into the module and can be accessed via the access() method. Sets isPreloaded() to true if data is found. Warning: Calling search() will overwrite any unpersisted local changes with server data. Events Emitted:
  • data_loaded - When search completes (whether data was found or not)
  • loading - Loading state changes
Example:

syncEntityId()

Synchronizes the entity ID from the session into the individual module. Signature:
Returns: void Description: Updates the individual’s entity ID to match the current session’s entity ID. Useful if the session entity ID changes after module initialization. Example:

Data Submission Methods

submit()

Persists all entity data to the server. Signature:
Parameters: Returns:
  • Promise<void> if verify is false (default) - Data saved, no verification run
  • Promise<CheckSummary> if verify is true - Returns verification results (see CheckSummary Structure below)
Description: Submits all individual data (name, DOB, documents, addresses, consents) to the server. When verify: true is passed, it also triggers verification checks and returns a summary of results. Retry behavior is not enabled by default. Pass retryOptions explicitly to enable automatic retries with exponential backoff. Events Emitted:
  • results - When verification completes (only if verify: true)
  • loading - Loading state changes
Examples:

runChecks()

Runs verification checks without submitting data. Signature:
Returns: Promise<CheckSummary> - Verification results Description: Triggers verification checks on the current entity data without performing a data submission. Use this to re-run checks on already-submitted data or to check verification status. Events Emitted:
  • results - When checks complete
  • loading - Loading state changes
Example:

CheckSummary Structure

Both submit({ verify: true }) and runChecks() return a CheckSummary object containing verification results.

Properties

Status Types

The status.type property indicates the overall verification result:

Example Structure


Data Access Methods

access(fieldName)

Accesses reactive data accessors for reading and updating entity fields. Signature:
Parameters: Returns: Accessor object Accessor Interface:
access() vs search():
  • Use access() to read or write entity data within the module. You don’t have direct access to the full raw entity object — access() is the interface for it.
  • Use search() to refresh entity data by fetching the latest state from FrankieOne’s backend.
Available Fields: Examples:

Name Methods

setEmail()

Sets the individual’s email address. Signature:
Parameters: Example:

getEmail()

Gets the individual’s email address. Signature:
Returns: string | null - Email address or null if not set Example:

setPhoneNumber()

Sets the individual’s phone number. Signature:
Parameters: Example:

getPhoneNumber()

Gets the individual’s phone number. Signature:
Returns: string | null - Phone number or null if not set Example:

Profile Methods

setProfileType()

Sets the verification profile type. Signature:
Parameters: Description: Sets the verification profile which determines what checks are performed during verification. The profile type corresponds to predefined verification workflows. Common Profile Types: Note: Profile types may be customized in your FrankieOne account configuration. Contact your account manager for custom profile options. Examples:

getProfileType()

Gets the current verification profile type. Signature:
Returns: void

addConsent()

Adds a consent string to the entity’s list of consents. Signature:
Parameters: Description: Records that the individual has provided a specific consent. Consent strings are stored and can be retrieved via access('consentsGiven'). Example:

Document Methods

addDocument()

Adds a new identity document to the entity. Signature:
Parameters: Example:

updateDocument()

Updates an existing document by its ID. Signature:
Parameters: Example:

deleteDocument()

Deletes a document by its ID. Signature:
Parameters: Example:

Address Methods

addAddress()

Adds a new address to the entity. Signature:
Parameters: Example:

updateAddress()

Updates an existing address by its ID. Signature:
Parameters: Example:

Reference Methods

addReference()

Attaches indexable references to the entity. Signature:
Overloads:
  1. Single parameter - Sets the customer reference (won’t override if already set)
  2. Two parameters - Sets a custom key-value reference pair
Parameters: Description: References are custom identifiers you can attach to entities for indexing and searching in your system. The customer reference is a special primary reference; additional key-value pairs can also be added. Examples:

Extra Data Methods

setExtraData()

Sets custom extra data on the entity. Signature:
Parameters: Description: Allows you to store arbitrary custom data with the entity. This can be used to pass application-specific information through the verification flow. Example:

Data Structures

Document Structure

When adding or updating documents, pass a plain object with these properties. The SDK will convert it internally. Example:

Address Structure

When adding or updating addresses, pass a plain object with these properties. The SDK will convert it internally. Example:

Events

The Individual module emits the following events:

data_loaded

Emitted when entity data has been loaded from the server. Arguments:
Example:

data_updated

Emitted when any data field changes. Arguments:
Example:

Common Events

The Individual module also emits common events inherited from the event system:
  • error - When an error occurs
  • warning - For non-critical warnings
  • info - Informational messages
  • loading - Loading state changes
See Event System Reference for details.

Complete Example


Best Practices

  1. Always call search() first - Load existing data before making changes to avoid overwriting user progress.
  2. Check isPersisted() before navigation - Warn users if they have unsaved changes.
  3. Use access() for reactive data - Subscribe to field changes for real-time UI updates.
  4. Handle verification results - Always check checkStatus after submit({ verify: true }).
  5. Validate data before submit - Check that required fields are populated before calling submit().
  6. Add proper error handling - Listen to error events and wrap async calls in try-catch blocks.
  7. Set consents explicitly - Always record user consent with addConsent() before verification.