Skip to main content
POST
Update Entity and Verify Details

Authorizations

​
api_key
string
header
required

API key issued by Frankie Financial. This will rotate regularly.

Headers

​
X-Frankie-CustomerID
string<uuid>
required

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-CustomerChildID
string<uuid>

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-Background
integer

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://docs.frankieone.com/docs/asynchronous-calls-backgrounding-processes

Required range: 0 <= x <= 1
​
X-Frankie-Channel
string

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.

Path Parameters

​
entityId
string<uuid>
required

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

​
checkType
string
default:profile
required

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.

​
resultLevel
enum<string>
required

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.
Available options:
simple,
summary,
full

Query Parameters

​
force
boolean

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

​
noInvalidate
boolean

Disable check result invalidation for this update request.

Body

application/json

The entity to be checked

Contains all the details we'll check regarding an Entity. It is assumed that this will grow over time.

Current supported check parameters:

  • entity: The Entity we're checking. This must be supplied.
​
entity
object
required

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

​
deviceCheckDetails
object

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.

Describes all of the checks that were carried out against an entity as part of our cascading check process. Because there are a number of steps involved in checking an entity, (including the use of past checks done by you or others), there is an overall summary check result that will tell you the final disposition of the the check you requested.

So if you requested a 2+2+governmentID+pep/sanctions/etc (i.e. everything) then there would have been several checks done in order to meet this requirement. Some may have even failed, but eventually we got there. The summary gives the final assessment, based on all available data.

Detailed writeups on how this all works can be found here: https://docs.frankieone.com/docs/understanding-check-results

​
blacklistCheckResults
object[]

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

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

​
checkResultsListSummaries
object[]

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

​
checkRisk
object

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

​
checkSummary
object

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

​
duplicateCheckResults
object[]

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

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

​
entity
object

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

​
entityProfileResult
object

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.

​
entityResult
object

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

​
fraudCheckResults
object

Collection of fraud check results for the entity.

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

​
manualCheckResults
object[]

Collection of check results for the manual KYC.

An array of one entry with the manual check result.

​
requestId
string<ulid>

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.

Example:

"01BFJA617JMJXEW6G7TDDXNSHX"

​
sharedBlocklistCheckResults
object[]

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).