Transaction Monitoring clients can now view the percentile distribution of impacted entities to help determine the appropriate decisioning thresholds to test.

Previously, clients were able to test scenarios by changing rule thresholds and seeing the total number of impacted entities as well as viewing a list of sample entities. By understanding the percentile spread across their customer base, clients can now better optimize their rules by making more informed decisions about setting and adjusting thresholds.

To try this feature, click on the “Show Thresholds” button for the appropriate aggregation to see the percentiles. Once the aggregation is finalized, click the "Test" button on the bottom of the window to see a sample of the impacted Entities with the updated logic (the full list can also be downloaded).

Alloy's Document Verification software development kit (SDK) has expanded to include ten new document types. A variety of income document verifications (see below) are now available to better support credit underwriting and Canadian dual authentication. Additionally, provincial and indigenous identity documents are now supported for onboarding Canadian applicants. Clients currently using the web SDK don't need to make any changes or download any new files—they can simply start using the new functionality.

The Following documents are now fully supported within Alloy's Document Verification SDK:

Identity documents:

• License (USA, UK and Canada)

• Passport

• Canada Provincial ID

• Canada Indigenous Card

Proof of income/tax documents:

• Paystub

• Bank Statement

• W-2

• 1099

• 1120

• 1065

• T1 (Canadian tax doc)

• T4 (Canadian tax doc)

To enable additional document types within the Alloy SDK, follow the steps below:

1. Set up document verification workflow(s) with relevant services

2. In your Journey, add a “DocV” node for each document type you want to collect. For example, a node for license OR passport and then a second node for paystub OR bank statement.

3. Download the Alloy SDK by running yarn add @alloyidentity/web-sdk. Further instructions are available for web, iOS, and Android.

4. In the initialization parameters, each journey node requires its own nested array. For example, if you wanted to collect a license OR passport AND a bank statement OR paystub, you would write: documents: [['license','passport'],['bank_statement','paystub']].

Once configured, your users can choose document types from the options you’ve selected, whether on web, iOS, or Android.

To learn more about the Alloy Document Verification SDK, view our documentation. If you'd like to add Alloy’s Document Verification SDK to your Alloy workflow, reach out to your CSM or [email protected] to learn more.

Transaction Monitoring clients can now build rules on transaction history and PII changes using more granular time range options including minutes and hours.

Furthermore, clients can also run aggregations at the transacting account level for entities with multiple accounts. Previously, aggregations could only be run on the entity as a whole. This change also extends to aggregations for counterparties; this means clients can create rules aggregating counterparty activity relating to a specific account.

These changes enable clients to configure more custom rules in order to better detect suspicious activity and reduce potential false positives for teams to review.

A new "Contact Support" widget has been added to the lower left corner of the Alloy dashboard, giving all clients the option to access help articles and submit a support ticket directly from the dashboard.

Clicking on the widget will give users the option to ask a question and see relevant articles. If they need additional help, they can submit a ticket to the Alloy support team from within the widget.

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.