Clients are now able to create Custom Lists directly from within Settings. This allows clients to go beyond just two list types - Allow Lists and Deny Lists - and have a more flexible use of lists during decisioning. (For example, a client may want to check against entities that are in restricted industries, or have lists that represent different levels of risks for more granular decisioning.)

We consolidated the Settings page to host all lists in one place. Each client can have one Allow List, one Deny List, and as many Custom Lists as they would like to use in their decisioning.

Clients can edit list details, such as name and description, by clicking the “edit” icon at the right side of the row.

Clients using Iovation, Threatmetrix or passing device attributes through the events API will now see details on each device associated with an entity in the Devices tab on the Entity page. Viewing all device data in a single place enables more informed and holistic decisioning on risk.

Clients on Journeys will see updates to the Journey Versions List, making it easier to navigate and understand the statuses of different versions. In the Journeys section of the Alloy Dashboard, click into an individual Journey to view the list of versions created for that specific Journey.

1. Activate a previous Journey Version by selecting “Set Active” in the options menu. When activated, the Journey Version number will remain the same. (Reactivating a previous Journey version will no longer create a new Journey version.)

2. An "Inactive" badge will now appear next to inactive previous Journey Versions under Status. Other Statuses include “Active” and “Draft”.

3. “Run Test” is now available within the options menu for Journey Versions labeled as “Active” or “Inactive”, in addition to “Draft”.

Screenshot 1

4. When a specific version is opened to display more details, it will now show date and time stamps for when the version has been set active and by whom.

5. All services used in a Journey Version are now visible within the version details.

6. The default filter on the Journey Versions page is set to show all versions: Active, Draft, and Inactive versions.

The Alloy SDK now supports a hosted link option which enables clients to effortlessly deploy step-ups and verify their customers using a generated link without spending engineering effort to build a dedicated webpage to host the SDK.

For clients who have this option enabled, a short link and QR will automatically be generated per entity when a Journey enters a step-up node. This link can be retrieved by an agent through the Journey Application in the dashboard and sent via SMS or email to the entity. Note: Alloy does not support sending the link via SMS or email on behalf of the customer.

Once the entity clicks on the link, the SDK and configured plug-in will render for the entity to complete their step-up verification. The QR code provides an additional option for in-branch purposes, allowing agents to have customers scan the code directly to complete their application.

To get started, navigate to Journey Application and click on the three dot menu in the entity panel for the entity you’d like to generate a link for. Ensure that the Journey has step-up nodes configured using the Alloy SDK. Click on the “View Hosted SDK Link” option which will open up a modal. 

A unique link and QR code will be generated and tied to the particular entity and Journey Application in question. The agent can copy and send the link to the customer or have the customer scan the QR code. This link will expire after 48 hours but the agent will be able to regenerate the link.

Clients using portfolio monitoring can now run portfolio workflows on business entities, allowing them to better monitor the health of their existing customer base on an ongoing basis. 

Please note: only one type of entity (e.g. person or business) can be evaluated in a single portfolio workflow.

To get started, simply select 'Business' as the Entity Type when creating a new portfolio workflow.

All clients leveraging Alloy Case Management to manage and file Suspicious Activity Reports (SAR) can now set up reminders in the dashboard to notify them to review the SAR and determine if a Continuing Activity Report that may need to be filed.

Financial institutions that file SARs with FinCEN may be required to file a continuing suspicious activity report after a 90-day review. To ensure reports are filed in a timely manner, clients can now set up reminders between 0-90 days for any SAR reports filed. Please note: reminders can only be set up for reports that have been accepted by FinCEN.

To set up the reminder:

• A new option to ‘Notify to review this report for continuing suspicious activity’ will be visible in the SAR form entry before submitting to FinCEN. 
• Alternatively, users can also enable notifications by selecting ‘Flag for 90 day review’ in the ellipses menu on the top right.

All agents that have the permission to receive a SAR reminder will get one at the specified time. To update permissions, navigate to Settings > Roles > Case Management and tick/untick the box for ‘Agent can receive a reminder to review a previously filed report’.

Clients can now configure a name for input attributes. The defined names can be used and referenced in different parts of the platform and review experience. 

All JQ-parsed input attributes that have a name defined in the workflow, will appear in the Rerun Application form. Clients who use the Rerun Application form to edit miskeys or other information during the review process will now be able to edit JQ-parsed input attributes in the form. The attributes will now appear in the form under Input Attributes section.

Please note: all existing attribute names have been backfilled with the JQ filter.

Clients using Allow and Deny Lists can now specify an expiration date when updating their lists to automatically approve or deny evaluations based on one or more PII elements for a given time period.

To get started, navigate to Settings, then select Denylist or Allowlist from the Settings menu. When adding record(s) to a list from the dashboard or via API, include a value for expires_at. When the list service is run in an evaluation, any values with ‘expires_at’ timestamps in the past will not be considered when denying or allowing.