Decisioning with Events

Background

Ongoing data, including Entities, Bank Accounts, Transactions, Logins and more are sent to Alloy as Events. Events are a flexible record type and can be used simply to store data in Alloy for data retention and future use ("data-storing events"), or to evaluate the Event and related records through policy logic ("monitored events").

Source Workflows

A Source Workflow is a workflow in your Alloy account that is used to monitor Events with business logic. Source Workflows can be real-time workflows which evaluate each Event submitted to the API, or a Portfolio Workflow which evaluates the relevant Events at a scheduled time.

Events submitted through Source Workflows will always create an Evaluation and may also trigger an Alert depending on the Evaluation's outcome and whether the Source Workflow is setup in an ongoing Journey.

Real-Time Execution

Real-time Source Workflows are invoked at the time when Alloy receives a request to our Events API, based on a mapping of the Event Type and Event Status. You can map multiple Source Workflows to the same Event Type to support different use cases.

Each Source Workflow may be attached to a conditional Journey, which executes depending on the Source Workflow's outcome. The Journey creates an Alert record and can be used to orchestrate downstream actions that occur in the lifecycle of the Event, such as:

  • Requesting documents or device authentication via additional step-up workflows.
  • Allowing agents to review the alert and determine if it warrants additional investigation.
  • Allowing agents to promote the alert to a case on the user and file SARs if appropriate

Portfolio (Scheduled) Execution

Portfolio Workflows are Workflows that executed on a scheduled-basis rather than at the time when an event is received. Portfolio Workflows can still reference data that's submitted to Alloy via the Events API, but they do not execute at the time when an Event is received. This means they don't require an Event mapping configuration.


Mapping Events by Type and Status

When Alloy receives a new Event request, we determine which (if any) real-time Source Workflows to execute based on an your Event Mapping settings. This mapping is configured in the Alloy dashboard and is based on two different fields in the Events payload:

FieldAPI FieldDescription
Event Typeevent_typeThe type of Event you're sending.
See the list of supported Event Types here.
Event Statusevent_statusThe status of the Event.
See more about Event Statuses in the next section.

All mappings must be defined using at least the Event Type field, and the possible values for Event Type are fixed. In contrast, mapping with Event Status is more flexible and supports custom status values in addition to Alloy's default values. You should use Event Status in your mapping whenever the status of a particular Event determines how that Event should be monitored, or whether it's monitored at all.