/business/international/profile

Retrieve a business profile from any country (AUS included).

• X-Frankie-CustomerID (header, 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 (header) — 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.

/business/international/search

Search for a business from any country (AUS included).

• X-Frankie-CustomerID (header, 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 (header) — 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.

/business/ownership/query

Create Business Entity and Query UBO (AUS Only)

• X-Frankie-CustomerID (header, 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 (header) — 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.
• checkType (query) — When creating a new check, we need to define the checks we wish to run. If this parameter is not supplied then the check will be based on a configured check type for each entity category. The checkType is make up of a comma separated list of the types of check we wish to run. The order is important, and must be of the form: - Entity Check (if you're running this). Choose one from the available options - ID Check (If you want this) - PEP Checks (again if you want this, choose one of the options) 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. 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. - "fraudid": 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. Pre-defined combinations: - "full": equivalent to "two_plus,id,pep_media" or "pep_media" if the target is an organisation. - "default": Currently defined as "two_plus,id" or "pep" if the target is an organisation. 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). Profile: - "profile": By arrangement with Frankie you can have a "profile" check type that applies checks according to a profile 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 act a little like the Pre-defined combinations above in that they can map to a defined list. But they offer a lot more besides, including rules for determining default settings, inbuild 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 the future of checks with Frankie Financial.
• entityCategories (query) — A comma separated list that specifies the categories of entities associated with the target organisation that will be checked. - organisation - Just the organisation itself. - ubos - All ultimate beneficial owners. - pseudo_ubos - Use an alterntive category when an organisation has no actual UBOs. The actual category to use is defined via configuration, default is no alterntive category. - direct_owners - All direct owners of the company, both organisations and individuals, may include UBOs for for simple ownership. - officers - All officers of the company - officers_directors - All directors of the company - officers_other - All non-director officers of the company - all - All direct and indirect owners, both organisations and individuals (including UBOs), and officers of all organisations.
• resultLevel (query) — The result level allows you to specify the level of detail returned for the entity check. You can choose summary or full.
• validation (query) — Should a validation check be run before the ownership query. The default is specified via configuration. The validation checks to see if the provided organisation is suitable for an ownership query by looking for the ACN in public data sources. Options are: - "on": Validate only when ACN is not provided. This is the typical default. - "acn": Validate even if ACN is provided. - "only": Like "acn" but only do validation query, don't proceed with ownership query. This option cannot be set as the default via configuration. - "off": Never validate. The Ownership query will then fail if an ACN is not provided.
• generateReport (query) — The type of human readable report, if any, to generate based on the ownership query results.
• includeHistorical (query) — If set to true, historical ownership data will be requested.
• onlyProfile (query) — If set to true, a full UBO report will not be requested.

/business/reports

Run Report(s) against a new or existing organisation entity (AUS Only).

• X-Frankie-CustomerID (header, 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 (header) — 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.
• reportTypes (query, required) — Define the report(s) you wish to run. You can request more than one as a comma separated list. Duplicates will be ignored. Note: These reports are different to the business details and UBO queries and are meant to provide deeper detail and background on a business or organisation. Current valid report types are: - creditScore - creditReport

/business/{entityId}/verify

Run KYC/AML Checks on Organisation and/or Associated Individuals.

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• checkType (query) — When creating a new check, we need to define the checks we wish to run. If this parameter is not supplied then the check will be based on a configured check type for each entity category. The checkType is make up of a comma separated list of the types of check we wish to run. The order is important, and must be of the form: - Entity Check (if you're running this). Choose one from the available options - ID Check (If you want this) - PEP Checks (again if you want this, choose one of the options) 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. 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. - "fraudid": 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. Pre-defined combinations: - "full": equivalent to "two_plus,id,pep_media" or "pep_media" if the target is an organisation. - "default": Currently defined as "two_plus,id" or "pep" if the target is an organisation. 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). Profile: - "profile": By arrangement with Frankie you can have a "profile" check type that applies checks according to a profile 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 act a little like the Pre-defined combinations above in that they can map to a defined list. But they offer a lot more besides, including rules for determining default settings, inbuild 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 the future of checks with Frankie Financial.
• entityCategories (query) — A comma separated list that specifies the categories of entities associated with the target organisation that will be checked. - organisation - Just the organisation itself. - ubos - All ultimate beneficial owners. - pseudo_ubos - Use an alterntive category when an organisation has no actual UBOs. The actual category to use is defined via configuration, default is no alterntive category. - direct_owners - All direct owners of the company, both organisations and individuals, may include UBOs for for simple ownership. - officers - All officers of the company - officers_directors - All directors of the company - officers_other - All non-director officers of the company - all - All direct and indirect owners, both organisations and individuals (including UBOs), and officers of all organisations.
• resultLevel (query) — The result level allows you to specify the level of detail returned for the entity check. You can choose summary or full.
• generateReport (query) — The type of human readable report, if any, to generate based on the ownership query results.

/document

Create New Document.

• X-Frankie-CustomerID (header, 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 (header) — 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.

/document/new/compare

Create Document and Compare to Original.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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

/document/new/scan

Create and OCR Scan Document.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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

/document/new/utility/process/compare

Create Document and Run Utility Price Comparison.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• planLimit (query) — The maximum number of plans to return

/document/new/verify

Create and Verify Document.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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

/document/search

Search For a Document !! EXPERIMENTAL !!

• X-Frankie-CustomerID (header, 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 (header) — 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.

/document/{documentId}

Delete Document.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document

/document/{documentId}

Retrieve Document Details

• X-Frankie-CustomerID (header, 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 (header) — 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.
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document

/document/{documentId}

Update Existing Document.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document
• noInvalidate (query) — Disable check result invalidation for this update request.

/document/{documentId}/checks

Retrieve Document Verification Check Details.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document

/document/{documentId}/compare

Update Document and Compare to Original.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document

/document/{documentId}/full

Retrieve Document and Scan Data

• X-Frankie-CustomerID (header, 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 (header) — 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.
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document

/document/{documentId}/scan

Update and OCR Scan Document

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document

/entity

Create New Entity.

• X-Frankie-CustomerID (header, 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 (header) — 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.

/document/{documentId}/utility/process/compare

Update Document and Run Utility Price Comparison.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document
• planLimit (query) — The maximum number of plans to return

/document/{documentId}/utility/process/consent

Provide Explicit Consent to Switch Utility Plans.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document

/document/{documentId}/utility/process/switch

Initiate Switching of Utility Plan.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document

/document/{documentId}/verify

Update and Verify Document.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• documentId (path, required) — The documentId returned previously from an earlier call to /check or /entity or /document

/entity/new/idvalidate/getToken

Create Entity and Get IDV Token

• X-Frankie-CustomerID (header, 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 (header) — 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.

/entity/new/verify/pushToMobile

Create Entity and Push Self-Verification Link

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• nopush (query) — If set to true, then no SMS/email will be pushed. It will be up to the API caller to manage the delivery of the link.

/entity/new/verify/{checkType}/{resultLevel}

Create and Verify Entity

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• checkType (path, 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 of 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. 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).
• resultLevel (path, 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.

/entity/search

Search for Entity

• X-Frankie-CustomerID (header, 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 (header) — 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.

/entity/{entityId}

Delete Entity

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity

/entity/{entityId}

Retrieve Entity Details

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity

/entity/{entityId}

Update Existing Entity.

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• noInvalidate (query) — Disable check result invalidation for this update request.

/entity/{entityId}/check/{checkId}/{checkClass}

Update Check Result States (Batch)

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• checkId (path, required) — The checkId returned previously from an earlier call to */verify
• checkClass (path, required) — Specify which check Class this action will apply to (PRO, BCRO etc.). Valid values are: - "pro": Update a Process Result Object - "bcro": Update a Background Check Result Object. The class IDs in the request must be the IDs from Background Check Result Object Containers. - "fraudlist": Update a fraud list Process Result Object. The class IDs in the request must be check sources from fraudlist Process Result Objects.

/entity/{entityId}/check/{checkId}/{checkClass}/{checkClassId}

Update Check Result State

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• checkId (path, required) — The checkId returned previously from an earlier call to */verify
• checkClass (path, required) — Specify which check Class this action will apply to (PRO, BCRO etc.). Valid values are: - "pro": Update a Process Result Object - "bcro": Update a Background Check Result Object. The class IDs in the request must be the IDs from Background Check Result Object Containers. - "fraudlist": Update a fraud list Process Result Object. The class IDs in the request must be check sources from fraudlist Process Result Objects.
• checkClassId (path, required) — A PRO/BCRO ID
• status (query, required) — Set the new status of the Check Class (PRO/BCRO). Valid values are: - "unknown" - "true_positive" - "true_positive_accept" - "true_positive_reject" - "false_positive" - "stale"
• undo (query) — Undo a prior operation.

/entity/{entityId}/checks

Retrieve Entity Verication Check Details

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• alldata (query) — Requests that literally all data should be included in the response to a "get checks" request. This is as opposed to a filtered view where expired results are by default not included for entities that have an assigned profile.

/entity/{entityId}/idvalidate/getToken

Update Entity and Get IDV Token

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity

/entity/{entityId}/flag/blacklist

Set Entity Blacklist State.

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• set (query, required) — Set the value of an entity flag.
• reason (query) — Set the reason for blacklisting. Valid values are: - "NO_REASON_SUPPLIED" - "FABRICATED_IDENTITY" - "IDENTITY_TAKEOVER" - "FALSIFIED_ID_DOCUMENTS" - "STOLEN_ID_DOCUMENTS" - "MERCHANT_FRAUD" - "NEVER_PAY_BUST_OUT" - "CONFLICTING_DATA_PROVIDED" - "MONEY_MULE" - "FALSE_FRAUD_CLAIM" - "FRAUDULENT_3RD_PARTY" - "COMPANY_TAKEOVER" - "FICTITIOUS_EMPLOYER" - "COLLUSIVE_EMPLOYER" - "OVER_VALUATION_OF_ASSETS" - "FALSIFIED_EMPLOYMENT_DETAILS" - "MANIPULATED_IDENTITY" - "SYNDICATED_FRAUD" - "INTERNAL_FRAUD" - "BANK_FRAUD" - "UNDISCLOSED_DATA" - "FALSE_HARDSHIP" - "SMR_REPORT_LODGED" - "2X_SMR_REPORTS_LODGED"
• blockedBy (query) — Specify who is setting the entity as blacklisted.
• attribute (query) — Specify the blacklisted attribute. Valid values are: - "ENTIRE_PROFILE" - "FULL_NAME" - "EMAIL_ADDRESS" - "PHONE_NUMBER" - "ID_DOCUMENT" - "MAILING_ADDRESS" - "RESIDENTIAL_ADDRESS"
• originalId (query) — Specify the Id of the matching blacklisted entity or single data-point.

/entity/{entityId}/flag/duplicate/{otherId}

Resolve Duplicate States.

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• otherId (path, required) — An entityId returned previously from an earlier call to /check or /entity. Used when an operation requires two entityIds
• set (query, required) — Set the value of an entity flag.

/entity/{entityId}/flag/monitor

Set Entity Ongoing AML Monitoring Status.

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• set (query, required) — Set the value of an entity flag.

/entity/{entityId}/flag/watchlist

Set Entity Watchlist State.

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• set (query, required) — Set the value of an entity flag.
• reason (query) — Set the reason for watchlisting. Valid values are: - "WAS_BLACKLISTED"
• comment (query) — A comment describing the reason for a request.

/entity/{entityId}/full

Retrieve Entity Details and Document Scan Data

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity

/entity/{entityId}/idvalidate/initProcess

Update Entity and Initiate IDV Process

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity

/entity/{entityId}/status

Update Entity States

• X-Frankie-CustomerID (header, 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 (header) — 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.
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• set (query) — The status of an entity. Valid values are: - "wait": Waiting for new details from entity. - "fail": Manually fail the onboarding process. - "archived": Hide entity from on onboarding. - "clear": Remove any of the above manual states as well as any manual risk. - "inactive": Hide entity and prevent any further operations on it. Cannot be cleared.
• risk (query) — The risk override setting for an entity. This value will be used until a verify result updates a real risk factor. Valid values are: - "low" - "medium" - "high" - "unacceptable" - "significant"
• comment (query) — A comment describing the reason for a request.

/entity/{entityId}/verify/pushToMobile

Update Entity and Push Self-Verification Link

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• nopush (query) — If set to true, then no SMS/email will be pushed. It will be up to the API caller to manage the delivery of the link.
• phase (query) — Set the Push To Mobile phase. Currently supported values: - 2

/entity/{entityId}/verify/{checkType}/{resultLevel}

Update Entity and Verify Details

• X-Frankie-CustomerID (header, 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 (header) — 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 (header) — 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
• entityId (path, required) — The entityId returned previously from an earlier call to /check or /entity
• checkType (path, 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 of 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. 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).
• resultLevel (path, 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.
• force (query) — Force the verification to run, overriding any data aging or past check
• noInvalidate (query) — Disable check result invalidation for this update request.

/retrieve/response/{requestId}

(Re)retrieve Response Result.

• X-Frankie-CustomerID (header, 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 (header) — 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.
• requestId (path, required) — This will be the same RequestId that was sent in the 202 acceptance response.
• payload (query) — Specifies the type of the payload field in the retrieved response. Default is 'string'.

/ruok

Service Status

• askingNicely (query) — If set to true, the request is being made politely.

/your/configured/path/{requestId}

Push Notification Payload

• requestId (path, required) — This will be the same RequestId that was sent in the 202 acceptance response.