Decision Engine

The purpose of the decision engine is to create an automated evaluation mechanism which helps us reduce the risk of fraud as well as improve customer experience with non-assisted enrollments. There are several logical units of evaluation which need to be considered in terms of decision mechanisms and these units are called Trust Factors.

Trust Factors

A Trust factor is a single logical unit of the decision engine which can result in one out of five possible outputs - HIGH / MEDIUM / LOW / UNAVAILABLE / UNKNOWN

  • HIGH (GREEN) - minimum value for successful onboarding with low percentage risk of possible fraud - should be automatically approved
  • MEDIUM (ORANGE) - minimum value for suspicious evaluation - all suspicious cases should be considered for manual review, depending on the business case or customer preferences
  • LOW (RED) - minimum value for negative evaluation which represent high percentage risk of possible fraud - all cases should be considered for automatic rejection
  • UNKNOWN - no value returned, probably due to processing error
  • UNAVAILABLE - no part of the evaluation process. Feature not available for given onboarding application

Trust Factors that are evaluated can be divided into three main categories; Biometric Trust Factors, Document Trust Factors, and Data Cross Check. Data Cross Check is an internal Trust Factor, and its outputs are fused into the other two Trust Factors on the Customer Dashboard. Each Trust Factor has its own mechanism of capturing possible fraud attacks. Each Trust Factor provides an output (Score). Low scores represent a high likelihood of a fraud attack. Each Trust Factor has a different range of scores, so we have a normalisation table for each of them

Preconditions for Trust Factor evaluation

Quality acts as a key factor of the whole evaluation mechanism, therefore we need to consider it as a precondition for our evaluations and we need to introduce quality measurements and thresholds for document and face images.

Face Quality Check

Is a mandatory precondition for every face-related Trust Factor. The typical attributes checked are presence, proximity, position, background uniformity, pitch angle, yaw angle, eye status, glass status, mouth status, lighting. There are several ways to measure the input quality; for example to use DOT-CORE endpoint - api/v1/detect/. DOT-Core must be set up for smooth detection.

In case of mobile devices / tablets devices the range should be:

  • min-eye-distance - 0.1
  • max-eye-distance - 0.35

In the case of PC / Laptop we will need to carry out testing to find the best ratio. 0.1 means - that the minimum size of the eye distance will be 10% of the whole width of the capture image.

Document Quality Check

This checks if the document has the correct brightness, sharpness, no hotspots, enough background borders, and if it isn’t too small. With document server, the best way of measuring the quality is to use “/api/v5/document/ocr” where you can set documentProperties you request from the document server to analyse the quality attributes of the captured document.

Document capture

QualityAttributeId.LIGHT, ComplianceRange.of(0.15d, 1), ComplianceRange.of(0.3d, 1)),
QualityAttributeId.FACE_CONFIDENCE, ComplianceRange.of(1500, 10000), ComplianceRange.of(2000, 10000)),
QualityAttributeId.POSITION, ComplianceRange.of(0, 0.25d),
QualityAttributeId.PROXIMITY, ComplianceRange.of(-0.35d, 0.35d),
QualityAttributeId.YAW_ANGLE, ComplianceRange.of(-4, 4),
QualityAttributeId.PITCH_ANGLE, ComplianceRange.of(-6, 2),
QualityAttributeId.EYE_STATUS, ComplianceRange.of(-500, 10000),
QualityAttributeId.MOUTH_STATUS, ComplianceRange.of(-2000,
QualityAttributeId.BRIGHTNESS, ComplianceRange.of(-8728, 6970),
QualityAttributeId.CONTRAST, ComplianceRange.of(-5500, 6122),
QualityAttributeId.SHADOW, ComplianceRange.of(-9900, 10000),
QualityAttributeId.SHARPNESS, ComplianceRange.of(-4336, 10000),
QualityAttributeId.UNIQUE_INTENSITY_LEVELS,
QualityAttributeId.GLASS_STATUS, ComplianceRange.of(-10000, 50),
QualityAttributeId.BACKGROUND_UNIFORMITY, ComplianceRange.of(100,
QualityAttributeId.BRIGHTNESS, ComplianceRange.of(-5000, 5000),
QualityAttributeId.CONTRAST, ComplianceRange.of(-5000, 5000),
QualityAttributeId.SHARPNESS, ComplianceRange.of(0, 10000),
QualityAttributeId.UNIQUE_INTENSITY_LEVELS, ComplianceRange.of(0, 10000), ComplianceRange.of(0, 10000)),

Raw score / Normalized score / Thresholds

Each Trust Factor provides, as the result of the evaluation process, a score (RAW SCORE). These are provided in different ranges, for example, passive liveness (-10,000, 10000) and document authenticity (0,1). Therefore, we need to normalise them before sending them to the Decision Engine. We have to provide a normalisation formula for each Trust Factor.

Normalization formula

((max_new_range - min_new_range)*(value_toNormalize - min_current_range)/(max_current_range - min_current_range)) + min_new_range

  • max_new_range - Maximum possible value of desired range
  • min_new_range - Minimum possible value of desired range
  • value_toNormalize - RawScore which needs to be normalized
  • max_current_range - Maximum possible value of current range
  • min_current_range - Minimum possible value of current range

Face trust factors

Passive Liveness

A key Trust Factor of the onboarding process which evaluates the liveness of a captured selfie photo and prevents various spoof attacks. Supported by Level 2 API

Prerequisites
Face detectUse /api/v6/face/detect/ for face detection and passive liveness raw score calculation
QualityCheck if the image quality attributes are within given range:
BRIGHTNESS (-7800; 5000)
CONTRAST (-5000;6000)
SHARPNESS(-4000;10000)
UNIQUE_INTESITY_LEVELS(500;10000)
PITCH_ANGLE(-15;15)
DataValue
RawScoreRange (scoreOfFaceDetect)(0; 100)
Thresholds(this could change based on FAR level)
LOW TO MEDIUM85
MEDIUM to HIGH90
Calculation Formula
PL<85.55: PL_TRUST= INT(PL)
PL>=85.55 and PL<86: ROUNDUP(PL)
PL>=86 and PL<90.87: PL_TRUST=INT(PL)
PL>=90.87:PL_TRUST= ROUNDUP(PL)
Example
Face detect returns raw score 800
Normalized score = ((100-0)*(800-(-10000))/(10000-(-10000)) = 54
TrustFactor level - MEDIUM

Face Verification

A strong and reliable trust factor by which you can verify a person’s identity by capturing a selfie image which is converted into a proprietary template and this template is compared against the template generated from identity document and/or Active Liveness frames. Supported by Level 2 API

Prerequisites
Face detectUse /api/v6/face/detect/ for face detection
QualityCheck if the image quality attributes are within given range:
BRIGHTNESS (-7800; 5000)
CONTRAST (-5000;6000)
SHARPNESS(-4000;10000)
UNIQUE_INTESITY_LEVELS(500;10000)
PITCH_ANGLE(-15;15)
Face verifyFor verification use endpoint: /api/v6/face/verify Selfie vs croppedFaceFromID
DataValue
RawScoreRange (scoreOfFaceDetect)(0; 100)
Thresholds(this could change based on FAR level)
LOW TO MEDIUM25
MEDIUM to HIGH35
Calculation Formula
No normalization
Example
Raw Score = 60
Trust factor level = HIGH

Document trust factors

Evaluates document authenticity based on criterias like color profile, display attack or field tampering.

Document Authenticity

checks if a document has any labeled, overlaid letters, or photos, on a given document. Supported by Level 2 API

Prerequisites
Enable authenticity checkUse /api/v5/document/ocr endpoint for authenticity detection
Enable it in the request
“documentProperties”: {
“authenticity”: {
“enabled”: true
},
Enable Quality checkEnable it in the request /api/v5/document/ocr<br"documentProperties": { …
“quality”: {
“enabled”: true
},

Check if the document image returns value: OK
DataValue
RawScoreRange(document authenticity score)(0; 1)
Thresholds
LOW TO MEDIUM50
MEDIUM to HIGH65
Calculation Formula
Use normalization formula
Example
Raw Score = 0,9
Normalized score = ((100-0)*(0,9-0)/(1-0)) = 90
Trust factor level = HIGH

In case of Level 1 SDK set this Trust factor to UNAVAILABLE.|

Color profile

checks if document has an authentic colour profile Supported by Level 2 API

Prerequisites
Enable color profile checkUse /api/v5/document/ocr endpoint for color similarity detection
Enable it in the request
“documentProperties”: {
“authenticity”: {
“enabled”: true
},
Enable Quality checkEnable it in the request /api/v5/document/ocr
“documentProperties”: {

“quality”: {
“enabled”: true
},
Check if the document image returns value: OK
DataValue
RawScoreRange(color profile score)(0; 1)
Thresholds
LOW TO MEDIUM6
MEDIUM to HIGH20
Calculation Formula
Use normalization formula
Example
Raw Score = 0,9
Normalized score = ((100-0)*(0,9-0)/(1-0)) = 90
Trust factor level = HIGH

In case of Level 1 SDK set this Trust factor to UNAVAILABLE.|

Display attack (moire) detection

Supported by Level 2 API

Prerequisites
Enable color profile checkUse /api/v5/document/ocr endpoint for color similarity detection
Enable it in the request
“documentProperties”: {
“authenticity”: {
“enabled”: true
},
Enable Quality checkEnable it in the request /api/v5/document/ocr
“documentProperties”: {

“quality”: {
“enabled”: true
},
Check if the document image returns value: OK
DataValue
RawScoreRange(DisplayAttack score)(0; 1)
Thresholds
LOW TO MEDIUM6
MEDIUM to HIGH20
Calculation Formula
Use normalization formula
Example
Raw Score = 0,9
Normalized score = ((100-0)*(0,9-0)/(1-0)) = 90
Trust factor level = HIGH

In case of Level 1 SDK set this Trust factor to UNAVAILABLE.|

OCR field recognition

extraction of textual data from ID document Supported by Level 2 API

Prerequisites
OCR recognitionUse /api/v5/document/ocr endpoint for OCR recognition
Enable Quality checkEnable it in the request /api/v5/document/ocr
“documentProperties”: {

“quality”: {
“enabled”: true
},
Check if the document image returns value: OK
DataValue
RawScoreRange(OCR confidence score per field)(0; 1)
Thresholds
LOW TO MEDIUM75
MEDIUM to HIGH90
Calculation Formula
RawScore = (sum of valid confidence scores)/(total number of fields)
Example
Raw Score = (0,7+0,84+0,92+0,85+0,94)/ 5 = 0,85
Normalized score = ((100-0)*(0,85-0)/(1-0)) = 85
Trust factor level = MEDIUM

In case of Level 1 SDK set this Trust factor to UNAVAILABLE |

Data crosscheck trust factors

Date of expiration

indicates if person’s document is still valid Supported by Level 2 API

Prerequisites
Document authenticityTrustFactor of authenticity is HIGH
OCR Date of ExpirationResult is above 0,85
Enable Quality checkCheck if the document image returns value: OK
DataValue
RawScoreRange(0; 100)
Thresholds
LOW TO MEDIUM100
MEDIUM to HIGH100
Calculation Formula
IF (Current date <= Date of expiration) ->RAW SCORE = 100
IF (Current date > Date of expiration) -> RAW SCORE = 0
There are only two possible options 0 or 100
Example
Raw Score = 0
Trust factor level = LOW

Age Verification

trust factor which indicates age difference vs current person’s age based on birthNumber (DOB) and age estimation from selfie photo and/or document face photo

Supported by Level 2 API

Prerequisites
Document authenticityTrustFactor of authenticity is HIGH
OCR Date of birthResult is above 0,85
Enable Quality checkCheck if the document image returns value: OK
Gather Age infoUse /api/v6/face/detect/ for age detection. But better approach would be to just fetch it from DB since you used this endpoint during other trust factors
DataValue
RawScoreRange (detected Age)(0; 100)
Thresholds
LOW TO MEDIUM75
MEDIUM to HIGH85
Calculation Formula
100 -
ABS - absolute value of age differences
Current_date - Current date when the onboarding was made
Date of birth - date of birth recognized from the ID
Age - detected by /api/v6/face/detect/ endpoint during previous steps
Example
Raw Score = 100 - ABS(42 - 32) = 90
Trust factor level = HIGH

MRZ vs OCR fields

trust factor which indicates discrepancy between OCR recognised fields and MRZ code

Supported by Level 2 API

Prerequisites
Document authenticityTrustFactor of authenticity is HIGH
OCR resultsResult is above 0,85
Enable Quality checkCheck if the document image returns value: OK
MRZ ChecksumVerify checksum of given MRZ
ISO Doc 9303 compliant MRZOnly these MRZs are suitable for data cross check - in short, these are 2 and 3-line MRZs. Documents with no MRZ or a 1-line MRZ should not be used for cross check and this field should not be returned on the review screen
DataValue
*RawScoreRange(0; 100)
Thresholds
LOW TO MEDIUM?
MEDIUM to HIGH?
Calculation Formula
Use levenshtein distance for calculation of distances for string comparisons
Output of each comparison should be a score with range - 0;100
Comparisons:
comparison rules:
Upper case
TRIM - whitespace removal
all attributes converted based on US7ASCII
Document_ID_number vs MRZ_Document_ID_number
OCR_First_Name vs MRZ_First_Name
OCR_Last_Name vs MRZ_Last_Name
OCR_Date of expiration vs MRZ_Date_of_expiration
Raw score = (sum of all comparison scores / number of comparisons)
Example
OCR _ ID_Number vs MRZ_Document_ID_number = 80
OCR_First_Name vs MRZ_First_Name = 90
OCR_Last_Name vs MRZ_Last_Name = 100
OCR_Date of expiration vs MRZ_Date_of_expiration = 100

Raw Score = (80+90+100+100) / 4 = 93 Trust factor level = HIGH |

Date of expiration (Level 1 SDK)

trust Factor which indicates if person’s document is still valid Supported by: Level 1 SDK

Prerequisites
Document capturedocument capture by Autocapture SDK
Data cross check of expiration date fields vs date of expiration must be the sameCheck if the field of expiration date recognized by OCR vs expiration date in MRZ string
DataValue
*RawScoreRange(0; 100)
Thresholds
LOW TO MEDIUM100
MEDIUM to HIGH100
Calculation Formula
IF (Current date <= Date of expiration) ->RAW SCORE = 100
IF (Current date > Date of expiration) -> RAW SCORE = 0
There are only two possible options 0 or 100
Example
Raw Score = 0
Trust factor level = LOW

Age Verification (Level 1 SDK)

trust factor which indicates age difference vs current person’s age based on birthNumber (DOB) and age estimation from selfie photo and/or document face photo Supported by: Level 1 SDK

Prerequisites
Document capturedocument capture by Autocapture SDK
birthNumber availabilityCheck if Date of birth field exists in OCR data:
Yes - use it for age verification
No - use MRZ Date of birth for age verification (as a fallback)
if both are not available, Age: UNKNOWN
DataValue
*RawScoreRange(0; 100)
Thresholds
LOW TO MEDIUM75
MEDIUM to HIGH85
Calculation Formula
100 - ABS((Current_date - date of birth) - (age))
ABS - absolute value of age differences
Current_date - Current date when the onboarding was made
Date of birth - date of birth recognized from the ID
Age - detected by /api/v6/face/detect/ endpoint during previous steps
Example
Raw Score = 100 - ABS(42 - 32) = 90
Trust factor level = HIGH

MRZ vs OCR fields (Level 1 SDK)

trust factor which indicates discrepancy between OCR recognised fields and MRZ code Supported by: Level 1 SDK

Prerequisites
Verify MRZ checksumVerify if MRZs checksum is correct
birthNumber availabilityCheck if Date of birth field exists in OCR data:
Yes - use it for age verification
No - use MRZ Date of birth for age verification (as a fallback)
if both are not available, Age: UNKNOWN
ISO Doc 9303 compliant MRZOnly these MRZs are suitable for data cross check - in short, these are 2 and 3-line MRZs. Documents with no MRZ or a 1-line MRZ should not be used for cross check and this field should not be returned on the review screen
DataValue
*RawScoreRange(0; 100)
Thresholds
LOW TO MEDIUM75
MEDIUM to HIGH90
Calculation Formula
Use levenshtein distance for calculation of distances for string comparisons
Output of each comparison should be a score with range - 0;100
Comparisons:
comparison rules:
Upper case
TRIM - whitespace removal
all attributes converted based on US7ASCII
Document_ID_number vs MRZ_Document_ID_number
OCR_Date of expiration vs MRZ_Date_of_expiration
Raw score = (sum of all comparison scores / number of comparisons)
Example
OCR _ ID_Number vs MRZ_Document_ID_number = 80
OCR_Date of expiration vs MRZ_Date_of_expiration = 100

Raw Score = (80+90+100+100) / 4 = 93 Trust factor level = HIGH |

Overall trust evaluation

In overall most of the onboarding records will be registered successfully which means that they were approved during the evaluation process and the onboarding application met all the criterias defined by Onboarding Trust platform. But of course there will be some cases where indicators will not allow to register the onboarding record automatically and these cases will require some reattempt of the whole onboarding procedure or cases will need some operator’s clarifications to finish the onboarding process.

Evaluation mechanism

Due to particular business criterias there are several trust factors which cannot be used during every decision evaluation. That’s why we need to introduce some sort of evaluation mechanism which will fit for every possible business requirement nevertheless we are going to use Level 2 SDKs or Level 1 SDKs. We currently provide two Document recognition SDKs: Level 1 SDK and Level 2 SDK. So the logic would be to have (currently two) separate endpoints dedicated either using Level 1 SDK or Level 2 SDK Each endpoint would consider various trust factor sets. For example Level 1 SDK does not support DisplayAttack,Color that’s why we cannot consider a particular trust factor for decision evaluation. So let’s create an evaluation builder or evaluation matrix per endpoint which would clearly identify which trust factor will be included in which decision evaluation endpoint.

Evaluation matrix

Evaluation matrix describes which endpoints are going to use which trust factor for decision evaluation. | Endpoint_1(Level 2 SDK) | Endpoint_2(Level 1 SDK) | |TrustFactors | TrustFactors| | Document: 3;4;5;6 | Document: | | Face: 1;2 | Face: 1;2 | | DataCross check: 5;6;7 | DataCross check: 10;11;12 |

Decision engine (Automatic resolution)

Another added value of the decision engine is the automated decision mechanism which will help us reduce the number of suspicious cases which need to be reviewed manually by setting up a few simple decision rules. Cases which will not be automatically registered belongs to one of two categories:

  • rejected onboarding records (REJECT action) - automatically rejected onboarding based on low trust scores of particular Trust Factor. If any of the trust factors will have a score LOW will be automatically rejected
  • suspicious onboarding records ( Manual review ) - If any of the trust factors will have a score MEDIUM AND no trust factors LOW scores will be automatically marked as suspicious which means moved for manual review.

Onboarding life cycle

UNIQUE - successfully registered onboarding records CAPTURED - unfinished onboardings - every started onboarding should should be inserted with CAPTURE state which reflects that onboarding is not completed due to one the following reasons

  • onboarding has not finished yet due to incomplete data
  • onboarding ended with an error due to any reason REVIEW - onboarding cases which ended as suspicious case based the outputs from decision engine(at least one trust factor ended with MEDIUM state)
  • once the operator opens the cases for review he can decide whether the onboarding will be UNIQUE(Accept button) or REJECTED(rejected) based on customers decision policy. REJECTED - automatically rejected onboarding due high probability of fraud

Overall score

There are several factors which could be considered as mandatory ,but I think for the MVP it’s enough to consider a few basic ones.

  • Accepted - only if all trust factors have HIGH trust level
  • Rejected - those onboardings which has at least one trust level with LOW level
  • To be reviewed - those onboarding which has at least one trust level with MEDIUM level

If any of the trust levels are not available due to any reason like issue during processing, or outage or any other reason,but the trust factor should be the part of evaluate lets just put it to NOTAVAILABLE level based on which we could ask the client to repeat the sequence or just that particular step.

All cases which would have at least one UNKNOWN could lower the overall score by one level or we can discuss what to do in those cases.

NOTE: End result is considered based on the lowest option example Age verification - HIGH Document authenticity - UNKNOWN Color profile - HIGH Overall score - MEDIUM

Changes History

2022-01-04

Changed calculation of Passive Liveness

2022-01-04

Changed Face Verification Thresholds

2022-01-12

First/Last Name removed from Cross Check logic (MRZ vs OCR)

2022-01-12

Age Verification (Level 1 SDK) updated

2021-06-05

Initial Release

2021-04-12

First Draft version