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:
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:
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:
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
search()
Searches for and loads existing entity data from the server.
Signature:
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
syncEntityId()
Synchronizes the entity ID from the session into the individual module.
Signature:
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:
Returns:
Promise<void>ifverifyisfalse(default) - Data saved, no verification runPromise<CheckSummary>ifverifyistrue- Returns verification results (see CheckSummary Structure below)
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 ifverify: true)loading- Loading state changes
runChecks()
Runs verification checks without submitting data.
Signature:
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 completeloading- Loading state changes
CheckSummary Structure
Bothsubmit({ verify: true }) and runChecks() return a CheckSummary object containing verification results.
Properties
Status Types
Thestatus.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:
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.
Examples:
Name Methods
setEmail()
Sets the individual’s email address.
Signature:
Example:
getEmail()
Gets the individual’s email address.
Signature:
string | null - Email address or null if not set
Example:
setPhoneNumber()
Sets the individual’s phone number.
Signature:
Example:
getPhoneNumber()
Gets the individual’s phone number.
Signature:
string | null - Phone number or null if not set
Example:
Profile Methods
setProfileType()
Sets the verification profile type.
Signature:
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:
void
Consent Methods
addConsent()
Adds a consent string to the entity’s list of consents.
Signature:
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:
Example:
updateDocument()
Updates an existing document by its ID.
Signature:
Example:
deleteDocument()
Deletes a document by its ID.
Signature:
Example:
Address Methods
addAddress()
Adds a new address to the entity.
Signature:
Example:
updateAddress()
Updates an existing address by its ID.
Signature:
Example:
Reference Methods
addReference()
Attaches indexable references to the entity.
Signature:
- Single parameter - Sets the customer reference (won’t override if already set)
- Two parameters - Sets a custom key-value reference pair
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:
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:
data_updated
Emitted when any data field changes.
Arguments:
Common Events
The Individual module also emits common events inherited from the event system:error- When an error occurswarning- For non-critical warningsinfo- Informational messagesloading- Loading state changes
Complete Example
Best Practices
-
Always call
search()first - Load existing data before making changes to avoid overwriting user progress. -
Check
isPersisted()before navigation - Warn users if they have unsaved changes. -
Use
access()for reactive data - Subscribe to field changes for real-time UI updates. -
Handle verification results - Always check
checkStatusaftersubmit({ verify: true }). -
Validate data before submit - Check that required fields are populated before calling
submit(). -
Add proper error handling - Listen to
errorevents and wrap async calls in try-catch blocks. -
Set consents explicitly - Always record user consent with
addConsent()before verification.