Skip to main content

How to add a new capability (API)

info

This guide is for clients who already integrated via API (POST /processes/v1) with Fraud Risk Classification (Trust Network) and are adding Identity Verification to their contract.

Adding Identity Verification

This guide explains the evolution of the decision engine to strengthen your identity validation processes.

Technical requirement

Unlike other integrations, enabling this capability requires updating your API key. Without this change, you will not be able to receive the new identity validation responses — your Unico contact will share them with you.

The big change: Identity Verification

The main improvement is the ability to validate the holder's identity (in addition to the fraud responses). The system now verifies whether the person performing the process is in fact the holder of the provided document.

It is critical that your team correctly understands and maps the new response interpretation before the capability is activated, so as not to impact your operation.

Result comparison table

Result (Trust only)Result (Trust + IDUnico)Meaning and recommended action
N/AAPPROVEDNew (ideal state). The user is the ID holder and there is no evidence of fraud.
INCONCLUSIVEINCONCLUSIVENuance change. The user is real and there is no evidence of fraud, but there is no certainty they are the ID holder.
REPROVEDREPROVEDRejection recommended. Fraud indicators, or the system confirmed the user is not the ID holder.
HIGH_RISKHIGH_RISKAt least one strong fraud evidence. The client decides the action.
CRITICAL_RISKCRITICAL_RISKAt least two critical fraud evidences. Rejection recommended.

Key changes in naming

Make sure your system is ready to map these three fundamental changes in your approval flow:

  1. The arrival of APPROVED — this is now the "ideal" state. If you receive this code, you have full certainty of the process's identity and safety.
  2. The new nuance of INCONCLUSIVE — previously your main green light. Now it means the person is "real" and there is no obvious fraud, but the system could not link them to the ID's identity with full certainty.
  3. The severity of REPROVED — besides multi-factor fraud indicators, this state now also includes cases where the user is impersonating the ID holder.