Appearance
Checks
Endpoints for interacting with EyeDP checks
Get case checks
Returns all the checks performed on a case.
| Endpoint | /api/cases/{caseId}/checks |
|---|---|
| Method | GET |
Response
json
[
{
"id": 206,
"createTs": "2025-08-20T15:51:17.303",
"checkName": "financial-vulnerability",
"documentIds": []
},
{
"id": 205,
"createTs": "2025-08-20T15:51:17.243",
"checkName": "kyc",
"documentIds": []
},
{
"id": 204,
"createTs": "2025-08-20T15:49:41.987",
"checkName": "content-validation",
"documentIds": []
}
]Details
| Field | Description |
|---|---|
| Id | Id of the check used to get the check results |
| CreateTs | Timestamp of the check |
| Check name | Name of the check |
| documentIds | If a check is on any of the case documents they will show up here. A bank account verification check lists the bank account's source document, or is empty when the account has none. |
Risk indicators
Every check result returned by /api/cases/{caseId}/checks/{checkId} includes a riskIndicators list. Each entry is a risk the check raised, along with its current rating. Use the id to remediate the risk.
json
{
"id": 205,
"checkName": "kyc",
"checkLabel": "KYC",
"checkDescription": "Know your customer",
"createTs": "2025-08-20T15:51:17.243",
"riskIndicators": [
{
"id": 96385,
"name": "KYC referred",
"description": "Only a partial identity match was found",
"riskRating": "Medium"
}
],
"kycResponse": { }
}Details
| Field | Description |
|---|---|
| id | Id of the risk indicator. Pass this to the remediate endpoint. |
| name | Name of the risk |
| description | Description of the risk |
| riskRating | The risk's current rating: Low, Medium, High or Information. AML risks can also be Unrated. Once a risk is remediated, this is the rating it was remediated to. |
The list is empty when the check didn't raise any risks. Risks that are disabled in your risk configuration aren't included.
Remediate risks
Gives one or more risks on a check a new rating, for example after you've reviewed a flagged result and are satisfied with it. Any alert raised for a remediated risk is resolved, and the remediation is recorded in the case log.
| Endpoint | /api/cases/{caseId}/checks/{checkId}/remediate |
|---|---|
| Method | POST |
Request
Remediate a single risk by passing its id. Only that risk is changed:
json
{
"riskIndicatorIds": [96385],
"riskRating": "Low",
"comment": "Verified with the customer"
}Pass several ids to give them all the same rating and comment in one request. To give risks different ratings, send a separate request for each:
json
{
"riskIndicatorIds": [96385, 96386],
"riskRating": "Low",
"comment": "Verified with the customer"
}Or leave out riskIndicatorIds to remediate every risk on the check:
json
{
"riskRating": "Low",
"comment": "Verified with the customer"
}| Field | Required | Description |
|---|---|---|
| riskIndicatorIds | No | Ids from the check's riskIndicators. Leave out to remediate every risk on the check. If included, it can't be an empty list. |
| riskRating | Yes | The new rating: Low, Medium, High or Information |
| comment | Yes | Why the risks were remediated, up to 300 characters. Shown against each risk and in the case log. |
Response
Lists the risks that were remediated. When riskIndicatorIds was left out, this is every risk on the check.
json
{
"riskIndicatorIds": [96385, 96386]
}Errors
A 400 Bad Request is returned, and nothing is remediated, when:
| Error | Cause |
|---|---|
| Check ID does not exist on case | The check isn't on the case in the URL |
| Risk indicators not found on check: ... | One or more ids aren't risks on this check. The ids are listed in the error. |
| riskIndicatorIds cannot be empty... | riskIndicatorIds was an empty list. Leave it out to remediate every risk. |
| riskRating must be Low, Medium, High or Information | riskRating was a rating that can't be assigned, such as Unrated |
| The RiskRating field is required. | riskRating was left out |
| The Comment field is required. | comment was left out or blank |
| The field Comment must be a string or array type with a maximum length of '300'. | comment was longer than 300 characters |
Check: Tamper detection
Returns tamper detection check results for a document. This check is triggered as soon as a document is uploaded to EyeDP.
If you also use Tamper Lite, you can choose to skip Tamper detection on a document where Tamper Lite raises a risk. A skipped Tamper detection has no result, so it isn't returned here or by Get case checks. Its run shows as Skipped in case progress. See Check: Tamper Lite.
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
json
{
"id": 1234,
"checkName": "tamper-detection",
"checkLabel": "Tamper Detection",
"checkDescription": "Tamper analysis on a provided document.",
"createTs": "2026-01-26T11:13:05.8",
"tamperDetectionResponse": {
"riskRating": "High",
"riskRatingLabel": "Pdf processed by editor",
"riskRatingDescription": "Document was processed using editing software",
"results": [
{
"title": "Declared document language is English (United Kingdom)",
"description": "The creator of this document declared English (United Kingdom) as the language of the document's content."
},
{
"title": "Saved in Microsoft Word",
"description": "The document was processed and saved in Microsoft Word - document tool from Microsoft."
},
{
"title": "No difference between creation and modification date",
"description": "The creation and modification dates in this document's metadata are the same, suggesting no updates were made after the file was first created."
}
]
}
}The tamper detection response contains an overall risk rating with details stored in the results section. The following table describes the fields in more depth.
| Field | Description |
|---|---|
| Risk Rating | This is the overall risk rating of the check. It is determined by your risk configuration set in the EyeDP portal. It can be the following values: Low, Medium, High or Informational |
| Risk Label | The label given to the risk |
| Risk Description | A brief high level explaination of the risk |
A full list of the possible risk labels can be found in the EyeDP portal config page.
Results
Tamper detection runs a lot of different check on the document. The results section give more details on the findings.
| Field | Description |
|---|---|
| Title | Short title of the tamper check |
| Description | Detailed description with more information of the tamper check |
Extra Metadata
There is extra metadata available when a query parameter of includeMetaData with a value of true is provided.
e.g. /api/cases/123/checks/123?includeMetaData=true
Enabling the metadata returns Document quality, document metadata and metadata on the tamper detection results.
Quality
Quality of the document resolution has three possible values: HIGH_QUALITY, LOW_QUALITY or NOT_RELEVANT_DOCUMENT
json
"quality": "HIGH_QUALITY"Document metadata
json
"documentMetadata": {
"producer": "Adobe PDF library 11.00",
"creator": "Adobe Illustrator CC 2014 (Macintosh)",
"creationDate": "2019-06-01T10:35:36-04:00",
"modificationDate": "2019-06-01T10:35:36-04:00"
}Bounding boxes
Bounding boxes are available for results such as Suspected Content Tampering. These are to show locations where tampering is suspected.
json
{
"title": "Suspected content tampering",
"description": "Some characters in the image differ from the typical visual patterns found elsewhere in the document. This may indicate digital manipulation or tampering.",
"code": "grp_content_tampering_suspected",
"type": "RISK",
"category": "modification",
"boundingBoxes": [
{
"pageId": 0,
"x": 405,
"y": 103,
"width": 4,
"height": 7
},
{
"pageId": 0,
"x": 446,
"y": 103,
"width": 5,
"height": 7
}
]
}Results Metadata
Some results such as 'Document has unexpected metadata' includes specific metadata to help explanations.
json
{
"title": "Document has unexpected metadata for this issuer",
"description": "The metadata, such as the document's creator, producer, or PDF version, differs from what is typically seen in documents from this issuer.",
"code": "anomalous_metadata",
"type": "RISK",
"category": "anomalous_metadata",
"boundingBoxes": [],
"resultData": [
{
"columnNames": [
"Key",
"Value"
],
"data": [
"PDFVersion",
"PDF-1.7"
]
}
]
}Check: Content validation
This type of check runs a set of rules against the contents of uploaded documents and the case itself. This check is triggered as soon as a document is uploaded to EyeDP.
The rules enabled in your setup can be accessed through the Portal: https://portal.eyedp.com
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
If any of the rules fail the endpoint will return the rules with the status as 'Failed':
json
{
"id": 230,
"createTs": "2025-08-22T13:45:25.01",
"contentValidationResponse": {
"rules": [
{
"status": "Failed",
"name": "Name",
"riskRating":"High",
"description": "Checks document name against Case name",
"documentIds": [
960
]
},
{
"status": "Failed",
"name": "Date of Birth",
"riskRating":"High",
"description": "Checks the document date of birth against Case date of birth",
"documentIds": [
960
]
},
{
"status": "Failed",
"name": "Document Expiry",
"riskRating":"Medium",
"description": "Document is approaching its expiration date.",
"documentIds": [
960
]
}
]
}
}Passed rules will return a status of 'Passed':
json
{
"id": 230,
"createTs": "2025-08-22T13:45:25.01",
"contentValidationResponse": {
"rules": [
{
"status": "Passed",
"name": "Joint account",
"description": "The platform will flag an alert if the document is in joint names",
"documentIds": [
960
]
}
]
}
}Details
The rules of the check contains the following fields
| Field | Description |
|---|---|
| Status | Status can be one of 3 options: Pending, Passed or Failed. Pending only appears while the rule is executing. Generally this is very quick so you probably won't see it. You're most likely to see it as either Passed or Failed which are the results of the rule. |
| Name | Short name of the rule |
| RiskRating | The risk rating according to your risk configuration. Possible values are: Low, Medium or High |
| Description | Longer more detailed description of the rule. For document expiration, this identifies whether the document is approaching its expiration date or has passed it. |
| DocumentIds | The documents involved in the rule. Rules that compare document contents like a Name against the case will only show a single Id. If the rule is looking at trends across documents all the document ids will be included. |
Check: Document Comparison
This type of check runs a set of rules that compares content across the documents uploaded to a case. This check is triggered as soon as a document is uploaded to EyeDP.
The rules enabled in your setup can be accessed through the Portal: https://portal.eyedp.com
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
Each Doc V Doc rule consists of multiple "entries" that describe what check was performed between two documents. The more documents on the case, the more entries per rule.
Each entry has its own result which are in turn used to compute the overall rule result. If any of entries flagged, the overall rule will be also be flagged. A rule passes only if all entries match.
We return both the result ID (enum) as well as the result text for convenience. Possible options are:
NotRan = 1,
Ok = 2,
Flagged = 3,
Failed = 4,json
{
"id": 6808,
"checkName": "document-comparison",
"checkLabel": "Document Comparison",
"checkDescription": "Compares data between documents on the case.",
"createTs": "2026-03-05T14:14:54.453",
"documentComparisonResponse": {
"docVDocRules": [
{
"id": 11,
"snapshotId": 1508,
"ruleId": 2,
"resultId": 3,
"operationId": 6808,
"checkText": "Different Date of Births were found across the documents",
"rule": {
"id": 2,
"name": "Date of Birth",
"shortDescription": "Compares the Date of Birth across documents",
"description": "Compares the Date of Birth across documents",
"riskFactorId": 73,
"documentTypes": [
"Passport",
"Driving Licence",
"Other"
]
},
"result": "Flagged",
"riskRating": "Medium",
"entries": [
{
"id": 448,
"docAId": 2098,
"docBId": 2102,
"docAType": "Driving Licence",
"docBType": "Driving Licence",
"resultId": 3,
"result": "Flagged",
"checkText": "Compared 29/01/1981 to 05/01/1964"
},
{
"id": 449,
"docAId": 2098,
"docBId": 2103,
"docAType": "Driving Licence",
"docBType": "Passport",
"resultId": 3,
"result": "Flagged",
"checkText": "Compared 29/01/1981 to 18/01/1963"
},
{
"id": 450,
"docAId": 2098,
"docBId": 2106,
"docAType": "Driving Licence",
"docBType": "Driving Licence",
"resultId": 2,
"result": "Matched",
"checkText": "Compared 29/01/1981 to 29/01/1981"
},
...
]
},
...
}
]Details
| Field | Description |
|---|---|
| Id | The ID of the rule execution |
| CheckText | Detailed summary of the result |
| Entries | A collection of comparisons performed when running the rule. See the Doc V Doc Rule Entries section |
| OperationId | The ID of the associated operation for this rule exeution |
| ResultId | The internal ID of the result. A text version is in Result |
| Result | A text version of the result. |
| RiskRating | The risk rating according to your risk configuration. Possible values are: Low, Medium or High |
| RuleId | The ID of the Doc V Doc Rule that this resultset belongs to |
| Rule | The Doc V Doc Rule this resultset ran against. See the Doc V Doc Rule section |
| SnapshotId | The Snapshot ID of the case that the rule was executed against |
Doc V Doc Rule
| Field | Description |
|---|---|
| Id | The ID of the rule |
| Description | Longer more detailed description of the rule |
| Name | The name of the rule |
| ShortDescription | A short description of the rule |
| RiskFactorId | The ID of the Risk Factor that this rule raises when flagged |
| DocumentTypes | A list of the Document Types that this rule runs against |
Doc V Doc Rule Entry
| Field | Description |
|---|---|
| Id | The ID of the rule run entry |
| DocAId | The ID of Doc A |
| DocBId | The ID of Doc B |
| DocAType | The type of Document A |
| DocBType | The type of Document B |
| ResultId | The internal ID of the result. A text version is in Result |
| Result | A text version of the result |
| CheckText | Detailed summary of this entry |
Check: KYC
Returns KYC check results for a case.
Case requirements
| Property | Notes |
|---|---|
| Dob | DOB is required to run eKYC (all three, DOBDay, DOBMonth, DOBYear) |
| Fullname | Fullname will work if supplied, the check separates into first & last name splitting on space |
| GivenNames & Surname | If Fullname isn't supplied a minimum of GivenNames has to be supplied |
| Address | Has to be split address cannot use FullAddress |
| CaseType | Has to be Individual |
This check is only triggered through executing workflows. Please see the workflows page.
Example cases
Use these in our Sandbox environment to test the check.
Loading example cases.
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
json
{
"id": 241,
"createTs": "2025-08-22T15:40:21.55",
"kycResponse": {
"decision": "Pass",
"rules": [
{
"ruleId": "7603",
"ruleName": "V_EId_2PSNAx",
"ruleScore": 1,
"ruleText": "2+ Primary or Secondary Name and Address (DoB agnostic)"
},
{
"ruleId": "6710",
"ruleName": "V_EId_1ScNAx",
"ruleScore": 1,
"ruleText": "At least one Primary or Secondary Data Source, with a name and address"
}
],
"matches": [
{
"matchType": "Name Only",
"matchKeyValues": [
{
"key": "Primary",
"value": 0
},
{
"key": "Secondary",
"value": 0
}
]
},
{
"matchType": "Name and DOB",
"matchKeyValues": [
{
"key": "Primary",
"value": 0
},
{
"key": "Secondary",
"value": 0
}
]
},
{
"matchType": "Name and DOB",
"matchKeyValues": [
{
"key": "Primary",
"value": 0
},
{
"key": "Secondary",
"value": 0
}
]
},
{
"matchType": "Name and Address",
"matchKeyValues": [
{
"key": "Primary",
"value": 1
},
{
"key": "Secondary",
"value": 0
}
]
},
{
"matchType": "Name, Address and DOB",
"matchKeyValues": [
{
"key": "Primary",
"value": 5
},
{
"key": "Secondary",
"value": 1
}
]
}
]
}
}Response breakdown
Decision
The overall decision of the KYC check. Possible values are:
| Result | Description |
|---|---|
| Pass | We've been able to verify the individual's identity successfully |
| Refer | We've only been to partially verify the individual's identity. Further review is required. |
| Fail | No verification of the person's identity could be found. |
Rules
Rules are ran on the matches found in the search. The outcome of the rules determines the overall KYC decision. A rule score of 1 means the conditions of the rule has been matched. A score of 0 means the conditions have not been matched.
EyeDP does have a standard ruleset. However, the exact rules you have will different depending on configuration.
The standard config is:
| Result | Conditions |
|---|---|
| Pass | 2+ Name+Address matches found from Primary or Secondary sources |
| Refer | At least one Name+Address match from a Primary or Secondary source |
Matches
The number of matches found in each data source category. They're broken down by match type such as 'Name and DOB' where the individual's name and dob have been found on a data source together. Or 'Name, Address and DOB' where every searched part of the individual has been found.
Primary match
These are authoritative, direct, and often government-verified records that provide a high level of confidence in an individual's identity. Examples are Electoral Register and Credit/Financial information.
Secondary match
These are generally less authoritative or easily obtained records that support or corroborate the information found in primary sources. Examples are Mobile phone data or utility records.
Check: Financial vulnerability
Returns Financial Vulnerability check results for a case.
Case requirements
| Property | Notes |
|---|---|
| Dob | DOB is required to run FinVul (all three, DOBDay, DOBMonth, DOBYear) |
| Fullname | Fullname will work if supplied, the check separates into first & last name splitting on space |
| GivenNames & Surname | If Fullname isn't supplied a minimum of GivenNames has to be supplied |
| Address | Has to be split address cannot use FullAddress |
| CaseType | Has to be Individual |
This check is only triggered through executing workflows. Please see the workflows page.
Example cases
Use these in our Sandbox environment to test the check.
Loading example cases.
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
json
{
"id": 242,
"createTs": "2025-08-22T15:40:22.69",
"finvulResponse": {
"decision": "Fail",
"rules": [
{
"ruleId": "C6506",
"ruleName": "V_PI_CCJ_5000",
"ruleScore": 0,
"ruleText": "One or more active CCJs with a total value over £5000 found"
}
]
}
}Check: Bank account verification
Returns Bank account verification (BAV) check results for a case.
BAV verifies that bank account details are valid and associated with the supplied account holder, for the supported countries. A BAV check is enqueued automatically when a bank account is created on the case (when the process is enabled) — either via Bank Account Management, or when a bank statement is uploaded and extracted (a bank account is created from the extracted details). See bank account formats for live field rules.
| Endpoint | /api/cases/{caseId}/checks/{checkId} |
|---|---|
| Method | GET |
Response
json
{
"id": 223,
"createTs": "2025-08-22T13:45:24.37",
"bavResponse": {
"decision": "Pass",
"isError": false,
"reasons": [
"The supplied account details match the account holder"
],
"rules": [
{
"ruleId": "CNS1004",
"ruleName": "BAV_Acc_Age_0_30_Days",
"ruleScore": 0,
"ruleText": "Data has been found to indicate that the account was opened in the last 30 days"
}
],
"scores": [
{
"name": "Bank account validation",
"score": 95
},
{
"name": "Personal details match",
"score": 90
},
{
"name": "Address match",
"score": 80
}
],
"branchData": [
{
"institutionName": "Bank Of Dave",
"branchName": "Leeds",
"telephoneNumber": "01130000000",
"subBranchNumber": 12,
"address": [
{
"address1": "1 High Street",
"address2": "Suite 2",
"address3": "Floor 3",
"town": "Leeds",
"county": "West Yorkshire"
}
]
}
],
"accountMatchType": "SoleAccount"
}
}Response breakdown
| Field | Description |
|---|---|
| Decision | Overall result of the check. Possible values: Pass, Refer, Fail |
| IsError | true when the third-party verification service could not return a decision |
| Reasons | Explanations that accompany the decision |
| Rules | Rules that were evaluated. A ruleScore of 1 means the rule matched; 0 means it did not |
| Scores | Match scores from 0 to 100. Person checks return scores such as Bank account validation, Personal details match and Address match. UK entity checks return scores such as Bank account validation, Company Name, Company Address, Company Name And Address and Proprietor Details |
| BranchData | Branch details for the verified account, including institution, branch name, phone, sub-branch number, and address |
| AccountMatchType | Type of account match. Possible values: SoleAccount, JointAccount, Company, NoMatch. Company means the account matched the organisation and is only returned for entity cases with a UK bank account. Entity cases with a non-UK bank account return SoleAccount, JointAccount or NoMatch |
Triggering a BAV check
A BAV check is enqueued automatically when a bank account is created on the case (when the BAV process is enabled for the client). That happens when you:
- Create a bank account via the API — see Verify by creating a bank account
- Upload a bank statement — after extraction completes, a bank account is created on the case from the extracted account details, which enqueues BAV in the same way. See Verify from a bank statement
You can also start (or re-run) a check by executing the bav workflow. Pass the bank account to verify using the bankAccountId workflow option. Get the bank account ID from List bank accounts.
| Endpoint | /api/workflows/execute |
|---|---|
| Method | POST |
| Content type | application/json |
Workflow options
| Name | Description |
|---|---|
| bankAccountId | ID of the bank account on the case to run BAV against |
Example
json
// Workflow request example with BAV options
{
"caseId": "123",
"workflowName": "bav",
"workflowOptions": {
"bankAccountId": "456"
}
}The check runs asynchronously. When it completes, a bank-account-verification/completed webhook is sent (see Webhooks). Poll List bank accounts for the latest attempt, or retrieve the check result with the check ID from the webhook.
Check: AML
The AML check searches the case against watchlist, sanctions, politically exposed people and adverse media datasets.
The check includes the Name, DOB and Country of the case in the search.
Case requirements
| Property | Notes |
|---|---|
| CaseType | Either Individual or Entity |
| Fullname / GivenNames / Surname | Individual cases only. Fullname will work if supplied; otherwise at least one of GivenNames or Surname must be supplied |
| Name | Entity cases only. The entity's name is required |
| Dob | Optional. If supplied it's passed through as-is (partial DOBs are fine) to help narrow matches, but AML will run without it |
| Address | Optional. If supplied it's passed through as-is to help narrow matches, but AML will run without it |
The check is synchronous and can be executed through the AML workflow
Request options
Options can be provided when executing the workflow.
| Name | Description |
|---|---|
| enableOngoingMonitoring | Boolean to enable on going monitoring (ongoing screening) of the case against the AML dataset |
ExternalReference parameter
The request includes an optional parameter called ExternalReference. This can be used to store your own internal identifier or reference number against the check.
If included, this value will act as an idempotency key. If a check exists against the same case with the same ExternalReference, the result from the previous run will be returned instead of a new check being performed.
Example
json
// Workflow request example with AML options
{
"caseId":"123",
"workflowName":"aml",
"workflowOptions":{
"enableOngoingMonitoring":"true"
},
"externalReference":"123456789"
}AML workflow execution response
See below for example responses for the AML workflow - check the Swagger definition for the full schema: https://api-sandbox.eyedp.com/swagger
This example shows an individual match found with a PEP, Sanction, Enforcement and Adverse Media entry:
json
// RESPONSE from /api/workflows/execute (200)
{
"checkId": 2006,
"amlResponse": {
"matches": [
{
"riskId": 3228,
"riskRating": "High",
"isOverridden": false,
"entityId": "WX0012050221",
"type": "Individual",
"name": "Maria Elena Santos",
"status": "Alive",
"datesOfBirth": [
"1965-03-15"
],
"placesOfBirth": [
"Place 1",
"Place 2"
],
"nationalities": [
"Natioinality 1",
"Natioinality 2",
],
"citizenships": [
"Citizenship 1",
"Citizenship 2"
],
"relationships": [
{
"group": "Associations",
"type": "Friend",
"entityId": 1253678,
"dateModified": "2001-01-01T01:01:01+00:00",
"entityName": "Name of associate",
"ownershipPercentage": 0.0,
"segments": "Enforcement,PEP,Sanction"
},
{
"group": "Family",
"type": "Ex-Wife",
"entityId": 23456789,
"dateModified": "2001-01-01T01:01:01+00:00",
"entityName": "Family name",
"ownershipPercentage": 0.0,
"segments": "PEP,Sanction"
},
{
"group": "Companies",
"type": "Affiliated Company",
"entityId": 34567890,
"dateModified": "2001-01-01T01:01:01+00:00",
"entityName": "Company name",
"ownershipPercentage": 0.0,
"segments": "Sanction"
},
],
"addresses": [
{
"value": "BR",
"type": "Current"
}
],
"watchlistEntries": [
{
"key": 1,
"type": "Pep",
"source": "Government Records",
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"Executive Branch",
"Finance"
]
},
{
"key": 2,
"type": "Sanctions",
"source": "Market authority",
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"Sanction List"
]
},
{
"key": 3,
"type": "AdverseMedia",
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"Money Laundering"
]
},
{
"key": 4,
"type": "Enforcements",
"source": "Country or origin",
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"War Crimes"
]
},
],
"watchlistEntriesInfo": {
"sanctions": [
{
"key": 5,
"source": "Ministry of country XYZ",
"dateModified": "2022-03-01T01:44:03+00:00",
"subCategories": [
"Sanction List"
],
"country": "Country"
}
],
"peps": [
{
"key": 6,
"source": "Government Records",
"dateModified": "2023-06-15T10:30:00+00:00",
"subCategories": [
"Executive Branch",
"Finance"
],
"country": "BR",
"status": "Inactive",
"isPrimary": true,
"governingInstitution": "Ministry of Finance",
"governingRole": "Minister",
"effectiveDate": "2010-01-15",
"effectiveDateType": "Appointed",
"expirationDate": "2014-12-31",
"expirationDateType": "Official"
}
],
"adverseMedias": [
{
"key": 7,
"dateModified": "2001-01-01T01:01:01+00:00",
"subCategories": [
"Money Laundering"
],
"description": "Incident"
}
],
"sourceItems": [
{
"key": 8,
"sourceURI": "https:// example",
"dateModified": "2022-01-01T01:01:01+00:00"
}
],
"enforcements": [
{
"key": 9,
"country": "International",
"source": "International Criminal Court",
"subCategories": [
"War Crimes"
],
"dateModified": "2001-01-01T01:01:01+00:00",
}
]
},
"comments": "comment text will be here",
"matchConfidenceScore": 100,
"aliases": [
{
"category": "None",
"type": "AKA",
"scriptType": "Basic Latin",
"firstName": "abc",
"lastName": "abc",
"middleName": "abc",
"fullName": "abc"
},
],
"gender": "Female"
}
]
}
}And here is one for an business match found with a Sanction, Enforcement and SOE entry:
json
// RESPONSE from /api/workflows/execute (200)
{
"checkId": 8083,
"amlResponse": {
"matches": [
{
"riskId": 22585,
"riskRating": "High",
"isOverridden": true,
"entityId": "WX0005513308",
"type": "Business",
"name": "Company Name",
"status": "NotApplicable",
"datesOfBirth": [],
"placesOfBirth": [],
"nationalities": [],
"citizenships": [],
"relationships": [
{
"group": "Companies",
"type": "Affiliated Company",
"entityId": 9191930,
"dateModified": "2018-07-06T01:41:09+00:00",
"entityName": "Company Name",
"ownershipPercentage": 0.0,
"segments": "Other,SOE"
}
],
"addresses": [
{
"city": "City Name",
"country": "Country Name",
"category": "Associated",
"type": "Unknown"
},
{
"city": "City Name",
"country": "Country Name",
"postalCode": "Postal Code",
"category": "Business",
"type": "Unknown"
}
],
"watchlistEntries": [
{
"key": 1,
"type": "Sanctions",
"source": "Source Name",
"dateModified": "2022-02-25T01:48:27+00:00",
"subCategories": [
"Sanction List"
]
},
{
"key": 236,
"type": "Enforcements",
"source": "Source Name",
"dateModified": "2017-08-28T09:10:35+00:00",
"subCategories": [
"Excluded Party"
]
}
],
"watchlistEntriesInfo": {
"sanctions": [
{
"key": 1,
"source": "Source Name",
"dateModified": "2022-02-25T01:48:27+00:00",
"subCategories": [
"Sanction List"
],
"country": "Country Name"
}
],
"peps": [],
"adverseMedias": [],
"sourceItems": [
{
"key": 8,
"sourceURI": "Source URL",
"dateModified": "2022-03-07T03:27:37+00:00"
}
],
"enforcements": [
{
"key": 236,
"country": "Country Name",
"source": "Source Name",
"subCategories": [
"Excluded Party"
],
"dateModified": "2017-08-28T09:10:35+00:00"
}
]
},
"comments": "AML check comments",
"matchConfidenceScore": 100,
"aliases": [
{
"category": "None",
"type": "AKA",
"scriptType": "Basic Latin",
"lastName": "Company Name",
"fullName": "Company Name"
}
],
"soes": [
{
"isActive": true,
"countryAssociations": [
{
"type": "Ownership",
"country": "Country 1",
"ownershipPercentage": 50.23
},
{
"type": "Ownership",
"country": "Country 2",
"ownershipPercentage": 0.86
}
],
"dateModified": "2017-07-03T07:39:35+00:00"
}
]
},
]
}
}Sandbox environment
When integrating with the sandbox environment, the following cases will produce the following results:
| Name | DOB | Country | Result Type |
|---|---|---|---|
| Maria Elena Santos | 1965-03-15 | BR | Single PEP |
| Viktor Mikhailovich Petrov | 1972-08-22 | RU | Single Sanctions |
| John Michael Patterson | 1980-11-05 | GB | Single Adverse Media |
| Ahmed Hassan Al-Masri | 1968-05-30 | EG | 2 PEPs + 1 Sanctions |
| Carlos Eduardo Mendez | 1975-02-14 | VE | 1 Sanctions + 3 Adverse Media |
| Li Wei Zhang | 1963-07-18 | CN | 2 Sanctions |
| Nikolai Ivanov | 1970-04-12 | BY | 2 separate matches • 1 PEP • 1 Sanctions |
| Isabella Rodriguez | 1978-09-25 | MX | 2 separate matches • 1 Adverse Media • 2 PEPs + 1 Sanctions |
| Omar Al-Rahman | 1969-12-03 | SY | 2 separate matches • 1 Sanctions + 3 Adverse Media • 2 Sanctions |
Create cases that contain these names (the names can be partial) and DOBs and perform the workflow execution.
Check: Anomaly Detection
Anomaly detection looks for discrepancies in the document's content that could indicate that it's been modified.
This check is triggered as soon as a document is uploaded to EyeDP.
Examples of discrepancies
- Duplicate transactions within a bank statement.
- Unusually long expiration dates on passports or driving licences.
- Bill amounts that don't add up on utility bills.
- Obviously fake account numbers like '123456789'
All of these would be found and highlighted by this check.
Response
The anomaly detection response contains a list of all checks completed on the document content.
- Every check has a name and category to classify the check.
- The result can be one of two values: 'Pass' or 'Fail'
- A description is added only when the check fails. This gives information on why it has failed.
json
{
"id": 123,
"checkName": "anomaly-detection",
"checkLabel": "Anomaly detection",
"checkDescription": "Checks for anomalies within the documents content",
"createTs": "2026-05-14T09:13:19.463",
"anomalyDetectionResponse": {
"checks": [
{
"name": "person_name",
"version": "1.0",
"category": "Placeholder_data",
"result": "Pass"
},
{
"name": "bill_number",
"version": "1.0",
"category": "Placeholder_data",
"result": "Fail",
"description": "Potential sample or dummy bill number detected: '00000000/0'."
},
{
"name": "provider_vat_reg_number",
"version": "1.0",
"category": "Placeholder_data",
"result": "Fail",
"description": "Potential sample or dummy provider VAT reg number detected: '000 0000 00'."
},
{
"name": "bill_date_after_period_end_date",
"version": "1.0",
"category": "Date_coverage",
"result": "Pass"
},
{
"name": "due_date_after_period_end_date",
"version": "1.0",
"category": "Date_coverage",
"result": "Pass"
},
{
"name": "period_end_after_period_start",
"version": "1.0",
"category": "Date_coverage",
"result": "Pass"
},
{
"name": "period_length_less_than_one_year",
"version": "1.0",
"category": "Date_coverage",
"result": "Pass"
},
{
"name": "total_amount_consistent_with_charges_and_usage",
"version": "1.0",
"category": "Internal_consistency",
"result": "Pass"
},
{
"name": "Required fields present",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Billing and due dates logical",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Billing period within bill date",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Monetary reconciliation (charges, VAT, total, amount due)",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Account/reference consistency between bill and payment slip",
"version": "1.0",
"category": "AI",
"result": "Pass"
},
{
"name": "Invoice / VAT / Bill number plausibility",
"version": "1.0",
"category": "AI",
"result": "Fail",
"description": "Several identifier fields appear to be placeholder or all zeros rather than plausible values: 'Bill number: 00000000/0', 'VAT registration number 000 0000 00'. These look like non-unique placeholders and are unexpected on a VAT invoice."
},
{
"name": "Supply identifier / meter reference presence",
"version": "1.0",
"category": "AI",
"result": "Fail",
"description": "Typical business electricity bills include a supply identifier (MPAN/MPRN) or meter number. No meter number, MPAN, or MPRN is present in the extracted content. The bill does mention 'based on ESTIMATED readings' but does not provide an explicit meter or supply ID to tie consumption to a supply."
},
{
"name": "Contact/phone number plausibility",
"version": "1.0",
"category": "AI",
"result": "Fail",
"description": "A contact phone number is extracted as '0000 000 0000' (and elsewhere '0330 100 005' also appears). The '0000 000 0000' string is almost certainly a placeholder and not a valid customer contact number; presence of both a realistic number and a zero-placeholder increases inconsistency."
}
]
}
}Check: Tamper Lite
Tamper Lite looks for high level discrepancies in a file's metadata and data fingerprint.
This check is triggered as soon as a document is uploaded to EyeDP.
If Tamper Detection is also enabled, both checks run on the document independently of each other, and both results are available.
You can instead choose to skip Tamper Detection on a document where Tamper Lite raises a risk, with the When Tamper Lite Raises a Risk setting. Tamper Lite then runs first. If it raises a risk (any of its checks is Flagged), Tamper Detection is skipped for that document: it produces no check result, its run shows as Skipped in case progress, and a tamper-detection/skipped webhook is sent. If Tamper Lite raises no risk, or fails, Tamper Detection runs as normal.
Checks
| Name | Description | Applies to file type |
|---|---|---|
| File type mismatch | Detects mismatches between the claimed file type and actual data. | All |
| Missing metadata | Detects if the document is missing common metadata fields. | All |
| Image resolution / file size | Detects if the image is an inappropriate resolution and/or file size. | Images |
| Identical file | Detects whether this exact file has been uploaded to the same case, any of your other cases, or the platform as a whole. Note that the file name does not matter, only the actual file data is checked. | All |
| Virus/malware | Detects for the presence of a virus/malware | All |
| Suspicious creation/modification date | Detects whether the creation or modification dates indicate an unusual editing timeline. | All |
| Suspicious document producer chain | Detects for evidence of a revision history or signs of editing software having been used. | All |
| Embedded code | Detects embedded code. E.g. a macro-enabled Excel sheet, or a PDF with embedded JavaScript. | All |
| Cryptographic signature invalid | Checks for the signature integrity of cryptographically signed PDFs to verify that the file has not been altered since it was signed. | PDFs |
| Physical alteration | Detects whether the document has been physically altered, e.g. correction fluid, hand written corrections/annotations, sticky notes, etc. | Images |
| All 4 corners | Detects whether a physical document has all 4 corners present | Images |
Response
The tamper lite response contains a list of all checks completed on the document content
Name and Description
Both fields give information on what the check did
Result
Each check contains a result
| Value | Description |
|---|---|
| Flagged | The check has found something suspicious |
| Ok | The check completed without finding anything suspicious |
| Errored | The check errored when attempting to complete |
| Not ran | The check was not ran. This could be because it was disabled completely or not applicable for this document type |
Explanation
The explanation field is a friendly text field explaining how the check generated the result
Response example
json
{
"id": 50113,
"checkName": "tamper-lite",
"checkLabel": "Tamper Lite",
"checkDescription": "Tamper analysis on a provided document",
"createTs": "2026-07-27T13:29:16.687",
"tamperLiteResponse": {
"checks": [
{
"checkId": "FileTypeMismatch",
"name": "File type mismatch",
"description": "Detects mismatches between the claimed file type and actual data.",
"result": "Ok",
"explanation": "Both the declared and detected file types are image/jpeg."
},
{
"checkId": "MissingMetadata",
"name": "Missing metadata",
"description": "Detects if the document is missing common metadata fields.",
"result": "Flagged",
"riskRating": "Low",
"explanation": "Meaningful provenance metadata was missing for detected type image/jpeg.",
"riskIndicatorId": 96385
},
{
"checkId": "ImageResolutionFileSize",
"name": "Image resolution / file size",
"description": "Detects if the image is an inappropriate resolution and/or file size.",
"result": "Flagged",
"riskRating": "High",
"explanation": "The shortest image edge was 473px, below the 1000px minimum.",
"riskIndicatorId": 96386
},
{
"checkId": "IdenticalFile",
"name": "Identical file",
"description": "Detects if this exact file content has been uploaded before.",
"result": "Ok",
"explanation": "No identical file(s) detected"
}
]
}
}