Clients using the Onfido SDK plug-in may see minor changes to the user experience due to a new Onfido version upgrade. The Onfido Web SDK v14.2.2 upgrade contains enhanced security and improved accessibility support.

No changes are required on the client side. Please see Onfido’s SDK changelog and Web SDK Migration documentation for full details.

Clients will now have more visibility into the triggered rules and outputs behind an evaluation, providing agents with the necessary context for why an individual was flagged for review. 

The expanded Outcome Reasons modal on review pages (such as the Evaluations, Application Review, and Transaction Evaluation pages) will provide:

• A plain language description of the rule (if provided), 
• The full underlying rule logic
• Visual indicators for the outcomes of each of the tags that denote whether they satisfied or did not satisfy the rule logic.

Clients using Ongoing Monitoring will benefit from additional insight into the specific transactions or account changes which contributed to threshold breach for more complex rules using aggregations. Rules that have this type of evidence associated with them will be indicated by a receipt icon.  We currently support ‘‘evidence’ for the following Ongoing complex outputs:

• Account history
• Transaction history
• Entity history

For clients on the SDK, when step-up nodes or hosted links expire, a dedicated screen appears to explain to the end user what happened.

Further details on when the expiration screen displays:

• Step-up node expiration where after a certain number of days, hours, and/or minutes, the application is automatically advanced to the node to which the expired outcome for that action is mapped. End users who attempt to re-open the SDK will see the expiration screen. This can be configured from the Journey graph node settings. 
• Hosted link expiration where the link will no longer surface the SDK experience. End users who attempt to re-open the SDK will see the expiration screen. This can be configured in SDK settings per SDK key.

[image of Expiration Screen]

Please note at this time, the copy on the expiration screen cannot be modified.

Clients can now merge multiple entities into a single entity through our new dedicated API endpoint. For instance, if a client identifies a duplicate entity, they can resolve this by calling the new endpoint to merge the duplicate entries and retain a single Alloy entity ID. All associated information with the duplicate entity will be retained in the merged record and be available for future decisioning and reviews for that entity.

For more information on how to leverage the endpoint please reference our documentation: https://developer.alloy.com/public/reference/post_entities-merge

Ongoing Journeys and their manual review nodes will now have available outcomes of "Suspicious" and "Dismissed" rather than "Approved" and "Denied". These new outcome names reflect the riskiness of a post-origination event, compared to the prior origination-centric language.

Any client using Journeys and the Ongoing product can begin utilizing these “Suspicious” and “Dismissed” outcomes in new Journeys and to modify outcomes for existing Ongoing Journeys.

These new outcomes are visible during Journey building and in the Review Queue. (Please note these new outcomes are not yet captured in analytics.)

The Identity Element Velocity (IEV) is an Alloy service used in workflows. It is intended to count the number of entities (or evaluations with distinct SSN’s) with a matching subset of PII elements that run through a client’s Alloy account. The goal of this rule is to catch potentially suspicious entities sharing the same PII combinations due to identity theft or fraud.

Some clients may have different workflows set up for different lines of business that are managed by distinct third-party account opening systems. These clients will want to ensure that when a single entity applies for multiple products, the entity is not mistakenly recounted by the IEV rule across workflows as multiple distinct entities.

Previously, the only option for the scope of the IEV count was across all workflows in an account. To address this, when editing a workflow, clients now have the option to scope the IEV count of entities with a matching subset of selected PII elements for a specific workflow. With this scope, an entity is counted in the velocity count if it’s at least been run through the current workflow, even if it has also been run through other workflows as well.

All clients will now be able to click into any tags presented on review pages (such as the Evaluations, Application Review, and Transaction Evaluation pages) to see the associated rule logic. By having insight into the specific rule logic that triggered action on the entity, your agents can benefit from a more transparent, contextualized and efficient review.

Ongoing Monitoring clients will see updates to the Transactions Evaluation page which will provide them with more visibility into transaction-level data to better enable them to navigate and manage reviews more efficiently. To navigate to this page from Case Management, click on the Evaluations icon under the ‘Tags Triggered’ panel to view more details.

Changes include:

• Detailed transaction summary: access more granular, contextual information based on the payment type, allowing for a deeper understanding of each transaction’s context and history.
• Overview of the transaction path: illustrates the status of the payment and how the funds have moved from the source account to the counterparty account.
• Counterparty matches: if you are also utilizing Alloy for counterparty screening, you’ll also be able to view potential watchlist matches related to that transaction and optionally be able to take action on it (i.e. dismiss/suppress or escalate).