Handling Risks

Partner API3 is designed to support a real-time interactive session with the End-User in order to create a positive experience while mitigating risk for the Financial Institution. Ensenta manages the End-User experience and risk through the use of ‘Risk Factors’. Risk factors can be elements or details of the check, or perhaps even information about the End-User, that helps the Financial Institution with making the decision as to whether or not accept the check(s).

Examples of some risk factors

• Back Signature Not Detected
• Large Amount
• Amount Variance Exceeds Threshold
• End-User performing transaction from an OFAC Denylisted Country

Currently, Ensenta has over 250 risk factors. Keep in mind that some risk factors do not apply to all products. As regulations change and technology advances, Ensenta constantly adds new risk factors to mitigate risk while providing the best user experience.

In order to handle checks appropriately, risk factors are defined by the Partner Reseller or Financial Institution. There are three different ways risk factors can be configured that result in an interaction with the End-User:

• Reject – Reject level risk factors indicates the item cannot be accepted through the mobile application. Examples of this include:

  • Items that exceed a certain dollar threshold
  • Checks with a suspicious routing or account number
  • Duplicate checks

• IsConfirmable – IsConfirmable risk factors indicate that a check should be reviewed by the End-User before completing the deposit. Examples of this include:

  • Confirming that the check is dated with the last 6 months
  • Confirming the back of the check has been properly endorsed
  • Confirming that the check amount is correct

Considerations when handling risk factors as you plan out your development of a single-check per deposit user experience:

• Do not hardcode risk factors IDs to drive the End-User experience – the End-User experience with the application should be driven by the Severity and IsConfirmable flags returned during the evaluation stage. It is not scalable to tailor an end-user experience based on each risk factor.
• Do not hardcode risk factor messaging – risk factor messaging is customizable on the Ensenta side and is a server generated message. Partner Resellers and Financial Institutions can easily customize the message by contacting Ensenta – no development work is required. Passing through Ensenta messaging is a requirement to pass Integration Certification.

How to Handle the RiskFactor Object

RiskFactor object parameters of interest:

• Severity: While there are several values possible for Severity, your only concern is if the severity is Severity=3 (Reject) or not.
• IsConfirmable: This condition indicates that there is something on the check that we would like the End-User to either confirm/validate is present and correct on the check or to be allowed to go back and fix either the amount or re-take the images after fixing something on the check (example being back endorsement).
• RiskFactorLocalizedDescription: In the scenarios where the deposit is not being immediately accepted, the standard expectation is that your app will display the verbiage within this parameter to the End-User (see Rainy Day Scenarios for user interface examples).

Here are the main scenarios you will need to be able to address within your app based on the GetDepositItem response :

SCENARIO	RISKFACTOR OBJECT DETAILS	HOW TO HANDLE
Happy Day	There are no risks returned.	There are no issues with the check, proceed with either with the optional GetCheckImage step or directly to the PostDepositBatch. See Happy Day for the associated flow diagram. See Check Capture Process – Happy Day Scenario for an example user interface .
RainyDay: Reject	If there are any risks returned with the following: Severity = 3 (Reject) IsConfirmable = false	Have a screen specific to rejected checks where it indicates the deposit could not be accepted due to the following reasons and list the RiskFactorLocalizedDescription in an unordered list for any risk factors that met this criterion. Options that should be made available for the End-User: Allow the End-User to start over within the same session (see GetSessionInfo). Allow the End-User to cancel the entire batch via CancelDepositBatch. Allow the End-User to leave the RDC portion of your app via EndSession. See Reject for the associated flow diagram. See Reject for an example user interface.
RainyDay: IsConfirmable	If risks are returned with the following: Severity = anything other than 3 (Reject) IsConfirmable = true	Have a screen specific to checks for IsConfirmable where the End-User is asked to review the following items and list the RiskFactorLocalizedDescription in an unordered list for any risk factors that met this criterion. Options that should be made available for the End-User: Allow the End-User to go back and fix any details as needed (see UpdateDepositItems) Allow the End-User to confirm everything is correct and complete the deposit by proceeding with either with the optional GetCheckImage step or directly to the PostDepositBatch step. See IsConfirmable for the associated flow diagram. See IsConfirmable for an example user interface.

If multiple scenarios are presented from the table above, they should be addressed in the following order:

• Rainy Day: Reject
• Rainy Day: IsConfirmable
• Happy Day