Agents can now assign applications to themselves and other agents from the Application Queue. This will prevent duplication of work between multiple agents and provide an audit trail of reviewer history. All clients using Journeys and the Application Queue will now see the new ‘Assign’ drop-down option on the right side of the application view.

1. The ‘Review’ button will remain disabled until an agent has been assigned.
2. Once users click on the ‘Assign’ button, a list of all applicable agents will be displayed for the user to select from.
3. Based on the permissions that are configured, admins will be able to assign applications to themselves and other agents. Agents will only be able to assign to themselves. Please note that for existing clients, these permissions will have to be manually configured for the different roles. For clients who start using Alloy after today, these permissions will be set up for them by default.
4. Once an agent has been assigned, their name will appear in the button and replace the ‘Assign’ text. The ‘Review’ button will be enabled once an agent is assigned. Agents can un-assign themselves from an application by clicking the 'x' to the right of their name.

Note: In the small edge case where more than one user is assigned to an application at the same time, we will assign it to the first agent and display an error message to the rest.

For clients using Journeys, applications that include multiple entities applying together are now supported within the Application Queue. This includes use cases that involves multiple applications for joint applications as well as business applications. Agents can now see applications that include multiple entities within a unified view and no longer have to toggle between multiple views in order to review each entity within an application. Both evaluation and journey application reviews can be handled from the same screen.

This functionality replaces our Groups feature in a more unified and user-friendly way. To view multi-entity applications within the Application Queue, clients must be integrated with Journeys and use the new “entities array” api schema. View our documentation for additional details.

If you’d like to try Journeys, reach out to your CSM or [email protected] to learn more.

Transaction Monitoring clients will now be able to designate two tiers of case management permissions: Agents, which have the first tier of case permissions, and Managers, which have the same first tier permission along with additional permissions with more flexibility.

Both Agents and Managers will be able to view cases of any case type.

Agents will only be able to update cases if they are assigned to it. If a case does not have anyone assigned yet, then an Agent can assign themselves to the case. However, an Agent cannot unassign another Agent from a case, assign themselves to a case if it is already assigned to another Agent or assign another Agent to a case.

Managers will be able to update the status, assign or unassign, and make changes to all case types.

Users can view their permissions in the Settings menu of the Alloy dashboard, under “Agents”:

Please note: only admins can make changes to add/remove permissions. To set this permission, go to Settings > Roles > Permissions.

All case assignment events, as well as case status changes, will be auditable within Alloy.

Transaction Monitoring clients can now aggregate additional transactional and account-level attributes to configure custom rules in order to better detect suspicious activity patterns including:

• Irregularities in counterparties,
• Changes in user behavior compared to historical transactional activity,
• Additional filters for MCC codes, reason codes, return codes,
• Successful and attempted linking of external funding accounts,
• Attempted PII changes such as address and phone numbers changes.

A log of Alloy’s outgoing webhooks is now available within the Settings menu of the Alloy dashboard, under "Webhook Logs."

You can filter/search by any column, free type search or search for anything contained in the webhook payload, for example, a specific entity token. You can also see the attempt number; Alloy will attempt to send all webhooks up to 10 times with exponential backoff. Click on a specific log to see more details, including all previous attempts for a webhook.

Clients using Journeys can now track any changes made to the Journey and view which version is active with Journey version management.

Versions are listed in a table in chronological order, in the order a Journey version was live in production. Draft versions are visible at the top of table. Users can see the dates the Journey was active, any notes, its current status and who created the Journey.

Changes to the Journey status, including the ability to edit a draft, can be made by clicking the ellipsis menu on the right side of the table for the corresponding version. The active Journey can be edited by clicking on the corresponding ellipsis menu and selecting ‘Use as Draft.’ Versions can also be archived using the ellipsis menu.

By clicking the corresponding arrow on the left side of the table, users can expand a version’s details to see the creation date, changes from the parent version (if applicable), the Journey token, and the workflows, document verification, action nodes and Journey outcomes configured within the Journey version.

To learn more about Journeys and Journey version management, view our documentation. If you’d like to try Journeys, reach out to your CSM or [email protected] to learn more.

Alloy’s Identity Element Velocity feature offers clients the ability to decision off of identity elements when they are seen across multiple entities; for example, detecting identities that share a SSN or phone number, then taking subsequent actions—such as tagging it informationally, running additional services or determining an outcome.

New updates to Identity Element Velocity include:

• The option to decision off of more identity elements, including email domain, mother’s maiden name and IP address.
• The ability to add more than one PII element to an IEV rule for the same evaluation (while keeping entities, timeframe and velocity count the same). For example, detecting other entities that have used both the same SSN and device alias in an evaluation within a timeframe.

For full details on how to use this feature, see our support article.

New changes have been made to the user interface for What-If Analysis, including the addition of a confidence level to show the level of certainty in the results of the analysis.

To learn more about What-If Analysis, view our documentation here.