Update Entity and Verify Details

POST

Take the details and documents provided in the entity, and set about verifying them all. So for example, you might extract:

  • The name from the entity.name object
  • The address from the entity.address object
  • The DoB..

All documents that are presently attached to the entity will also be verified (if requested)

You can also specify the level of detail returned using the resultLevel parameter. You can choose “summary” or “full”. For the “profile” check type you can also select “simple” to only get the entity profile result.

SPECIAL NOTE: A “Full” response includes details of all checks and how they map against each element, along with all the details of pep/sanctions/etc checks too.

Your account also needs to be configured to support a full response too (talk to your account manager for more information). If you’re not configured for full responses, we’ll only return summary level data regardless.

Path parameters

entityIdstringRequired

The entityId returned previously from an earlier call to /check or /entity

checkTypestringRequired

When creating a new check, you need to define the checks you wish to run.

The checkType is make up of a comma separated list of the types of check you wish to run. The order of the requested checks is not important, they will be re-ordered by the service and in some cases, depending on your account configuration, may be skipped.

The validation that is performed on the requested checks is to:

  • ensure the check type is known
  • is suitable for the type of entity (no KYC for organisations)
  • disallow manual (mKYC) check with any other kind of KYC
  • disallow mixing the “profile” check with any other kind of check.

The supported check types are:

Profile:

  • “profile”: By arrangement with Frankie we will create a “profile” check type that applies checks according to a recipe that you assign to the entity from a predefined set of profiles.

The profile to use will be taken from the entity.entityProfile field if set, or be run through a set of configurable rules to determine which one to use.

Profiles provide a pre-defined combination of individual checkTypes (see the list below). But they offer a lot more besides, including rules for determining default settings, inbuilt data aging and other configurable features. They also allow for a new result set top be returned that provides a more detailed and useful breakdown of the check/verification process.

Entity Profiles are a recent feature (since v1.4.0) but are now the default checkType to use with Frankie Financial.

Individual Check Types

Whilst we strongly recommend the use of the “profile” checktype, it does map to any combination of the types below. If you wish to use these individually, please contact developer support for more details on how to use these effectively.

Entity Checks - One of:

  • “one_plus”: Checks name, address and DoB against a minimum of 1 data source. (also known as a 1+1)
  • “two_plus”: Checks name, address and DoB against a minimum of 2 independent data sources (also known as a 2+2)

ID Checks - One of:

  • “id”: Checks all of the identity documents, but not necessarily the entity itself independently. Use this in conjunction with a one_plus or two_plus for more.
  • ”visa”:

ID Validate - One of:

  • “idvalidate”: Checks to see if photo ID has had OCR scanning, ID document validation and photo comparison run against it. Can be used in conjunction with any of the KYC/ID/AML checks.

Manual Check:

  • “manual”: (mKYC) Checks user has a sufficient amount of operator verified ID and will then “pass” all Entity and ID related checks.

Fraud Checks - One or more of:

  • “fraudlist”: Checks to see if the identity appears on any known fraud lists. Should be run after KYC/ID checks have passed.
  • ”fraudcheck”: Checks external ID services to see if details appear in fraud detection services (e.g. EmailAge or FraudNet)

PEP Checks - One of:

  • “pep”: Will only run PEP/Sanctions checks (no identity verification)
  • “pep_media”: Will run PEP/Sanctions checks, as well as watchlist and adverse media checks. (no identity verification)
  • NOTE: These checks will ONLY run if either the KYC/ID checks have been run prior, or it is the only check requested.

Device checks:

  • “device”: This will allow you to pass in device details captured through services like ThreatMetrix or Sardine.ai

Custom:

  • By arrangement with Frankie you can define your own KYC check type.

This will allow you to set the minimum number of matches for:

  • name
  • date of birth
  • address
  • government id

This allows for alternatives to the “standard” two_plus or one_plus (note, these can be overridden too). Speak with the Customer Success team when you’re onboarding.

resultLevelenumRequired

How much detail we return.

Acceptable values are:

  • simple - Only available with “profile” check type. Returns just an EntityProfileResultObject (which is also included for “profile” checks at the other result levels), and a CheckEntityCheckResultObjectEntityResult with just the entity details but no separate results.
  • summary
  • full - You need to have your account configured for this.
Allowed values: simplesummaryfull

Headers

X-Frankie-CustomerIDstringRequired

Customer ID issued by Frankie Financial. This will never change. Your API key, which is mapped to this identity, will change over time.

X-Frankie-CustomerChildIDstringOptional

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.

X-Frankie-BackgroundintegerOptional

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

X-Frankie-ChannelstringOptional

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:

  • api
  • portal
  • smartui

Any alphanumeric string is supported though. Anything over 64 characters will be truncated.

Query parameters

forcebooleanOptional

Force the verification to run, overriding any data aging or past check

noInvalidatebooleanOptional

Disable check result invalidation for this update request.

Request

This endpoint expects an object.
entityobjectRequired

Describes all of the data being used to verify an entity.

deviceCheckDetailsobjectOptional

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.

Response

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.

blacklistCheckResultslist of objectsOptional

Collection of check results for the entity having been previously blacklisted.

An array of matched blacklisted entities sorted by match confidence level (highest first).

checkResultsListSummarieslist of objectsOptional

Contains a list of all checkSummary records (one for each check)

checkRiskobjectOptional

Stores the generic results of a process (check, scan, compare, verify, etc)

checkSummaryobjectOptional

Stores the generic results of a process (check, scan, compare, verify, etc)

duplicateCheckResultslist of objectsOptional

Collection of check results for the entity having previously been checked.

An array of matched checked entities sorted by match confidence level (highest first).

entityobjectOptional

Describes all of the data being used to verify an entity.

entityProfileResultobjectOptional

Contains the results of a check against an entity profile.

The entityProfileResult will be returned instead of a checkSummary to provide the full details of the verification process.

entityResultobjectOptional

This will hold all of the check results that were performed against the

fraudCheckResultsobjectOptional

Collection of fraud check results for the entity.

Contains fraud list and/or background result arrays. Other fraud check types will appear over time

manualCheckResultslist of objectsOptional

Collection of check results for the manual KYC.

An array of one entry with the manual check result.

requestIdstringOptional

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.

sharedBlocklistCheckResultslist of objectsOptional

Collection of check results for the entity having been previously blacklisted in shared blocklist.

An array of matched blacklisted entities sorted by match confidence level (highest first).

(International) Retrieve a business profile from any country.
Built with