Update an entity object and if successful, start the process of downloading the captured data and processing the reports and results of the ID validation process.
At a minimum, the entity will need to have a name. For best results, you should gather the DoB, address, ID document details as well before calling this initProcess function, or supply the details as part of this update.
The IDV process may run various checks against the photos and videos supplied by the applicant.
These check types are configured on request and can include:
- ID Validation (Document) - Looks at the picture(s) of the identity document, and does checks about image quality, as well as specific things about the id itself, such as whether it is expired or is for someone under 18. The image is also OCR’d and the OCR results are compared against the data entered for any KYC checks to make sure that it is the same document.
- Facial Photo Comparison - Compares the portrait picture of the identity document, to the “selfie” taken as part of the idv process. The selfie can be either a still photo or a live video (preferred). This checks both that the selfie taken is valid and not manipulated, and that it is a reasonable match to the picture on the identity document. The exact algorithm to determine matches and quality is dependant on the provider chosen.
- Facial Duplicate - Compares the selfie provided with previous selfies for other applicants. This check type is trying to identify based on the selfie whether this applicant has already registered under a different name and potentially with faked identification. If there is a potential match then the applicant is flagged for review.
The entityId returned previously from an earlier call to /check or /entity
Customer ID issued by Frankie Financial. This will never change. Your API key, which is mapped to this identity, will change over time.
If, as a Frankie Customer, you are acting on behalf of your own customers, then you can populate this field with a Frankie-assigned ID.
Note: If using a CustomerChildID, you will also need a separate api_key for each child.
Any documents, checks, entities that are created when this field has been populated will now be tied to this CustomerID + CustomerChildID combination. Just as Customers cannot see data created by other Customers, so too a Customer’s Children will not be able to see each other’s data.
A Customer can see the documents/entities and checks of all their Children.
Open string that can be used to define the “channel” the request comes in from. It can potentially be used in routing and risk calculations upon request. Default values that can be used are:
Any alphanumeric string is supported though. Anything over 64 characters will be truncated.
If this header parameter is supplied and set to 1, then the request will not wait for the process to finish, and will return a 202 if there are no obvious errors in the input. The request will then run in the background and send a notification back to the customer. See out callback API for details on this.
See more details here: https://apidocs.frankiefinancial.com/docs/asynchronous-calls-backgrounding-processes
Describes all of the data being used to verify an entity.
Contains any/all details we want to pass on to the device checking service as part of an activity / transaction. A transaction isn’t just a payment, but can represent a number of different interaction types. See below for more.
NOTE: If you’re sending this data, then your recipe or requested checkTypes MUST include a “device” checkType. Otherwise this data will be ignored and dropped.
The request was valid and able to be processed in some fashion. Results may or may not be successful, but it was completed as far as practical with no actual errors. Returns the entity object as it stands now. No docScan file data from any attached ID documents will be returned unless the /full variant is requested.
Also returned is the applicantId and token to be in the IDV process.
The applicantId is either the same one that was supplied in the request for a fresh token, or a new one. This ID must be supplied along with the token to your SDK so that it knows who any uploaded documents are for.
The latest applicant will also be written to the extraData of the entity as well for safe keeping. Older applicantIds will be overwritten.
Describes all of the data being used to verify an entity.
Unique identifier for every request. Can be used for tracking down answers with technical support.
Uses the ULID format (a time-based, sortable UUID)
Note: this will be different for every request.
Token to be used in the SDK to authenticate the applicant and application/referrer.
Tokens are time limited (1 hour) and can only be used with the applicantId supplied.
If the requesting customer can support requesting 2 documents.