How to Handle Workflow Results in Jumio?

Handling workflow results effectively is essential to ensure a smooth and secure identity verification process. In Jumio, workflow results provide valuable insights into the outcome of each verification step, enabling your business logic to determine the appropriate next actions for users.

This guide outlines best practices and key considerations for interpreting workflow results and implementing decision logic—helping you streamline user experiences, reduce friction, and maintain compliance and security standards.

Top-Level Decision Object

The top-level object in the Jumio response consists of a score and a type by default. This logic results from evaluating the applicable capabilities.

Additionally, if configured with a ruleset ID, Jumio can apply a decision-mapping layer that summarizes complex verification outcomes into clear, standardized result codes.

This optional feature makes it easier to understand why a transaction was rejected or flagged by surfacing the underlying reason directly in the top-level response.

• Please ask your Jumio representative for assistance with enabling this, if desired. Doing so will allow the results of the ruleset to be displayed at the top-level workflow response object for easy decisioning.
• Otherwise, your business logic will need to parse through the capabilities in the response to determine where any irregularities occurred (see table below for common handling decisions for various outcomes).

Standard Jumio Verification Rules

note

Jumio includes some default behavior that you may wish to change. Speak to an Integration Specialist at Jumio to learn about how to align this behavior to your use case requirements.

Some examples include:

• Jumio rejects photocopied documents by default.
• By default, multiple people detection occurs during the liveness detection capability.
• Repeated faces result in “WARNING” decisions.
• Jumio does not, by default, return “WARNING” decisions for expired documents – this needs to be configured with assistance from your Jumio representative.

Recommended Actions for Common Verification Outcomes

The following table summarizes common Jumio results and suggested actions for handling them. These examples are not exhaustive and should be adapted to your specific business logic and risk requirements.

Step / Capability	Jumio Result	Common Action
Risk Score = 0	Low risk	Indicates low or no detected risk. Approve the user.
Usability	REJECTED	If a transaction comes back with REJECTED for the Usability category, that doesn’t necessarily mean that it’s a fraudulent transaction. It just means that the user wasn’t able to provide suitable images for the transaction, as described by the specific decision detail label. Common next steps are to prompt to retry, perhaps on a different channel. For example, if the user formerly completed the transaction on their desktop browser, invite them to try again on their mobile browser, etc.
Usability	WARNING	Route accordingly based on your use case requirements for the country/document. Check country settings and evaluate internally.
Extraction	REJECTED	Extraction is always either passed or not executed. NOT_EXECUTED can be the result of a competing automation setting configuration. This could be an artifact of an automated extraction issue or a “missing mandatory data point,” e.g., a required data point was not able to be extracted (such as if some glare were blurring the DOB field on a document, etc.).
Image Checks	REJECTED	Typically maps to fraud/bad actor. Make your decision a specific function of the decision label.
Image Checks	WARNING	There are currently only three WARNING decision labels for this category: Different person Repeated face Ghost image quality insufficient Additional detail about each of these exceptions is described here. Each should be uniquely handled with regard to your use case requirements. It is strongly recommended to implement Jumio’s update account endpoint to minimize the occurrence of repeated faces to only those transactions that are not expected to be affiliated with the same account ID.
Data Checks	REJECTED	Typically maps to fraud/bad actor. However, make your decision a specific function of the decision label.
Data Checks	WARNING	Handle each of these as needed by your use case requirements, as each can be quite particular.
Liveness	REJECTED	Typically maps to fraud/bad actor. Each decision label possibility should be circumstantial and reviewed to align with your specific business use case requirements. Handle individually based on the specific reject reason (e.g., multiple people) to create some exception handling.
Liveness	WARNING	Each decision label possibility should be circumstantial and reviewed to align with your specific business use case requirements.
Similarity	NO_MATCH	Handle circumstantially.
Similarity	NOT_POSSIBLE	Hyper edge case, handle circumstantially.

note

• A rejection in any single capability will result in a rejection for the entire transaction.
• Many rejection reasons are highly specific and should be treated as edge cases, as they may not always indicate fraudulent behavior. For example, while most Image Check – REJECTED decision labels typically suggest potential fraud, the PUNCHED decision label may not necessarily imply fraudulent intent.

tip

Need help building this into your code or platform? Contact our Support team.